[fdo-internals] Question about FDOOGRProvider

[Gabriele Monfardini]

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/b1c280bc/attachment.html>