<div dir="ltr">I've been working on some large GeoPackage files that have a lot of layers. One in particular has over 5000 layers. It was taking a good 5+ minutes just to open, so I did some analysis. Here's what I found:<div><br></div><div>By far the biggest hit is in a query to sqlite_master (called from OGRGeoPackageTableLayer::ReadTableDefinition()). This is the particular query (in my dataset, this query generally takes about 90ms):</div><div><br></div><div><div>"SELECT type FROM sqlite_master WHERE lower(name) = lower('%q') AND type "</div><div>            "IN ('view', 'table')"</div><div><br></div><div>The calls to lower means it has to do a full table scan, but there isn't an index on sqlite_master, so just removing it doesn't change anything right away (it's still a table scan). I was able to optimize this by creating a temp table from sqlite_master in GDALGeoPackageDataset::Open(), updating it so name is all lower case, then creating an index on name. The one time cost of this process was about 100ms, but when I query instead of sqlite_master, it shaved down each query to <1ms. With 5000+ layers, this cut several minutes off time to open a dataset.</div><div><br></div><div>I have a patch for this, but I wasn't sure who to submit it to. There are also several other places in GDAL where queries to sqlite_master can be optimized, so I wanted to talk about it before I waste time refactoring other code. Is this a patch the maintainers would be interested in integrating?</div>-- <br><div class="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></div>