s

PRAGMA schema.cache_size; PRAGMA schema.cache_size = pages; PRAGMA schema.cache_size = -kibibytes; Query or change the suggested maximum number of database disk pages that SQLite will hold in memory at once per open database file. Whether or not this suggestion is honored is at the discretion of the Application Defined Page Cache. The default page cache that is built into SQLite honors the request, however alternative application-defined page cache implementations may choose to interpret the suggested cache size in different ways or to ignore it altogether. The default suggested cache size is -2000, which means the cache size is limited to 2048000 bytes of memory. The default suggested cache size can be altered using the SQLITE_DEFAULT_CACHE_SIZE compile-time options. The TEMP database has a default suggested cache size of 0 pages. If the argument N is positive then the suggested cache size is set to N. If the argument N is negative, then the number of cache pages is adjusted to be a number of pages that would use approximately abs(N*1024) bytes of memory based on the current page size. SQLite remembers the number of pages in the page cache, not the amount of memory used. So if you set the cache size using a negative number and subsequently change the page size (using the PRAGMA page_size command) then the maximum amount of cache memory will go up or down in proportion to the change in page size. Backwards compatibility note: The behavior of cache_size with a negative N was different prior to version 3.7.10 (2012-01-16). In earlier versions, the number of pages in the cache was set to the absolute value of N. When you change the cache size using the cache_size pragma, the change only endures for the current session. The cache size reverts to the default value when the database is closed and reopened. The default page cache implemention does not allocate the full amount of cache memory all at once. Cache memory is allocated in smaller chunks on an as-needed basis. The page_cache setting is a (suggested) upper bound on the amount of memory that the cache can use, not the amount of memory it will use all of the time. This is the behavior of the default page cache implementation, but an application defined page cache is free to behave differently if it wants.

OGR SQL dialect and SQLITE SQL dialect

The GDALDataset supports executing commands against a datasource via the GDALDataset::ExecuteSQL() method. How such commands are evaluated is dependent on the datasets.

For most file formats (e.g. Shapefiles, GeoJSON, MapInfo files), the built-in OGR SQL dialect dialect will be used by defaults. It is also possible to request the SQL SQLite dialect alternate dialect to be used, which will use the SQLite engine to evaluate commands on GDAL datasets.

All OGR drivers for database systems: MySQL, PostgreSQL / PostGIS, Oracle Spatial, SQLite / Spatialite RDBMS, GPKG -- GeoPackage vector, ODBC RDBMS, ESRI Personal GeoDatabase, SAP HANA and MSSQLSpatial - Microsoft SQL Server Spatial Database, override the GDALDataset::ExecuteSQL() function with dedicated implementation and, by default, pass the SQL statements directly to the underlying RDBMS. In these cases the SQL syntax varies in some particulars from OGR SQL. Also, anything possible in SQL can then be accomplished for these particular databases. Generally, only the result of SELECT statements will be returned as layers. For those drivers, it is also possible to explicitly request the OGRSQL and SQLITE dialects, although performance will generally be much less as the native SQL engine of those database systems.

SQL is executed against an GDALDataset, not against a specific layer