<div dir="ltr">Ok, yes, thank you, the code in the trunk made a huge difference. I appreciated it!</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 22, 2018 at 3:21 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Kevin,<br>
<span class=""><br>
> I've been working on some large GeoPackage files that have a lot of layers.<br>
> One in particular has over 5000 layers. It was taking a good 5+ minutes<br>
> just to open, so I did some analysis. Here's what I found:<br>
><br>
> By far the biggest hit is in a query to sqlite_master (called<br>
> from OGRGeoPackageTableLayer::<wbr>ReadTableDefinition()). This is the<br>
> particular query (in my dataset, this query generally takes about 90ms):<br>
><br>
> "SELECT type FROM sqlite_master WHERE lower(name) = lower('%q') AND type "<br>
>             "IN ('view', 'table')"<br>
><br>
> The calls to lower means it has to do a full table scan, but there isn't an<br>
> index on sqlite_master, so just removing it doesn't change anything right<br>
> away (it's still a table scan). I was able to optimize this by creating a<br>
> temp table from sqlite_master in GDALGeoPackageDataset::Open(), updating it<br>
> so name is all lower case, then creating an index on name. The one time<br>
> cost of this process was about 100ms, but when I query instead of<br>
> sqlite_master, it shaved down each query to <1ms. With 5000+ layers, this<br>
> cut several minutes off time to open a dataset.<br>
<br>
</span>You should re-try with GDAL trunk. I've had this same issue a few weeks/months<br>
ago and this should be fixed now per<br>
<a href="https://trac.osgeo.org/gdal/changeset/40474" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/<wbr>changeset/40474</a><br>
(please use latest trunk and not only this patch, as I somehow remember later<br>
fixes were needed)<br>
<br>
The reason for this lower case comparison if I remember well was to add<br>
compatibility with GeoPacakage databases created by ArcMap where there was<br>
inconsistent case used.<br>
See <a href="https://trac.osgeo.org/gdal/ticket/6916" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/<wbr>ticket/6916</a><br>
<span class="HOEnZb"><font color="#888888"><br>
Even<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Kevin Bentley<div>Cognitics, Inc.<br><font size="1">947 E Winding Creek Drive #200</font><div><font size="1">Eagle, ID 83616-7231<br><a value="+12089043780" style="color:rgb(17,85,204)">(208) 904-3780</a> (Office)<br><a value="+12088904472" style="color:rgb(17,85,204)">(208) 890-4472</a> (Cell)<br><a value="+18669222037" style="color:rgb(17,85,204)">(866) 922-2037</a> (Fax)</font><br></div></div></div></div>
</div>