[fdo-internals] Question about FDOOGRProvider

[Greg Boone]

I suppose one could call that function using FALSE, and only use TRUE on error

OGRErr err = m_connection->GetOGRDataSource()->GetLayer(m_nIndex)->GetExtent(&e, FALSE);
If (err)
    err = m_connection->GetOGRDataSource()->GetLayer(m_nIndex)->GetExtent(&e, TRUE);

Greg


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Gabriele Monfardini
Sent: Wednesday, March 26, 2014 9:57 AM
To: FDO Internals Mail List
Subject: [fdo-internals] Question about FDOOGRProvider

Hi all,

I had a PostgreSQL/Postgis database with some schemas and many tables.
I'm connecting to it using MapGuide 2.5.2 (centos 6), OGR provider (FDO 3.8.0) and a recompiled gdal/ogr library to support PostgreSQL.

All is working fine except for one thing.
The first time that a map that use this db is opened it takes tens of seconds to appear.
After the first time, the same map is opened in 3-4 seconds as it should.

Investigating this issue the problem seems to be in schema discovery since purging cached schema information from maestro triggers again the slow start.

Analyzing database log I've found that MapGuide seems to try to evaluate the extent of each geometry table in the database (brutally querying SELECT Extent(the_geom) on all of them).

And we happen to have a few very complicated views, defined from several other views, which are used in a totally unrelated project and never in MapGuide. Querying the extent of those views eats a lot of seconds.

Probably the called function is FdoByteArray* OgrSpatialContextReader::GetExtent() in OgrProvider.cpp.


At line 664, in function
FdoByteArray* OgrSpatialContextReader::GetExtent() GetExtent from OGR library is called

/*OGRErr err =*/ m_connection->GetOGRDataSource()->GetLayer(m_nIndex)->GetExtent(&e, TRUE);


From OGR documentation the second parameter is a boolean called bForce

Returns the extent (MBR) of the data in the layer. If bForce is FALSE, and it would be expensive to establish the extent then OGRERR_FAILURE will be returned indicating that the extent isn't know. If bForce is TRUE then some implementations will actually scan the entire layer once to compute the MBR of all the features in the layer.

This seems to be the case in my situation, that evaluating the extent is expensive.

From the code it does not seem to be any check to detect an OGRERR_FAILURE.

In your opinion (since I'm not familiar at all with FDO code) it would be feasible to pass bForce=false and maybe to cope with a possible failure?

Regards,

Gabriele Monfardini


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/fdo-internals/attachments/20140326/57e55bdb/attachment.html>