<div dir="ltr"><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">Hi all,</span><div style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></div><div style="font-family:arial,sans-serif;font-size:12.727272033691406px">
I had a PostgreSQL/Postgis database with some schemas and many tables.</div><div style="font-family:arial,sans-serif;font-size:12.727272033691406px">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.</div>
<div style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></div><div style="font-family:arial,sans-serif;font-size:12.727272033691406px">All is working fine except for one thing.</div><div style="font-family:arial,sans-serif;font-size:12.727272033691406px">
The first time that a map that use this db is opened it takes tens of seconds to appear.</div><div style="font-family:arial,sans-serif;font-size:12.727272033691406px">After the first time, the same map is opened in 3-4 seconds as it should.</div>
<div style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></div><div style="font-family:arial,sans-serif;font-size:12.727272033691406px">Investigating this issue the problem seems to be in schema discovery since purging cached schema information from maestro triggers again the slow start.</div>
<div style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></div><div style="font-family:arial,sans-serif;font-size:12.727272033691406px">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).</div>
<div style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></div><div style="font-family:arial,sans-serif;font-size:12.727272033691406px">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.</div>
<div style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></div><div style="font-family:arial,sans-serif;font-size:12.727272033691406px">Probably the called function is FdoByteArray* OgrSpatialContextReader::GetExtent() in OgrProvider.cpp.</div>
<div style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></div>
<div style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></div></div><div style="font-family:arial,sans-serif;font-size:12.727272033691406px">At line 664, in function </div><div style="font-family:arial,sans-serif;font-size:12.727272033691406px">
FdoByteArray* OgrSpatialContextReader::GetExtent() GetExtent from OGR library is called</div><div style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<font face="arial, sans-serif">/*OGRErr err =*/ m_connection->GetOGRDataSource()->GetLayer(m_nIndex)->GetExtent(&e, TRUE);</font></blockquote><div><br></div><div><br></div><div>From OGR documentation the second parameter is a boolean called bForce</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="color:rgb(0,0,0);font-family:'Lucida Grande',Verdana,Geneva,Arial,sans-serif;font-size:12px;background-color:rgb(251,252,253)">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.</span></blockquote>
<div><br></div><div>This seems to be the case in my situation, that evaluating the extent is expensive.</div><div><br></div><div>From the code it does not seem to be any check to detect an OGRERR_FAILURE.</div><div><br></div>
<div>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?</div><div><br></div><div>Regards,</div><div><br></div><div>Gabriele Monfardini</div>
<div><br></div><div> </div>
</div>