-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/05/14 21:09, James K. Lowden wrote: > I took "statement cache" to mean that execution plans would persist > either past sqlite3_exec() or that many plan would be kept, in case > later useful, when sqlite3_step() recompiles according to passed > parameters. I think that's unlikely to help much, and might hurt.
Statement cache means something front-ending sqlite3_prepare. A simple implementation would be updating sqlite3_finalize to stash the statement in a (bounded) hash table keyed by the SQL. Then in sqlite3_prepare look in the hash table for the SQL and return the stashed statement on match. (There are a few more subtleties.) > You're talking about using one prepared statement repeatedly, which, > if nothing else, is convenient. Statement cache sizes seem to be between 10 and 100 entries in various implementations I looked at. > And the application can always maintain its "cache" of > prepared-statement handles. Ah, for the olden days :-) Where exactly would this cache live? What if you are using several different libraries and modules that don't know about each other? What about various ORMs? The olden days where the app developer is responsible for every line of code in the app and they all work together well, including cooperating over a SQLite statement cache are a rarity now. Ask these questions: - - Should app/library developers using SQLite have to implement their own caching mechanism? - - Why did the majority of developers writing wrappers for SQLite spend the extra effort to also implement caches? BTW my answer for the second one is because statement preparation showed up in profiling, both outside and inside SQLite. The outside bit was because of having to do UTF8 conversion from native string representation, and inside because statement preparation takes a while - it involves parsing, many memory allocations and lots of other fiddly stuff. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlN7rRMACgkQmOOfHg372QRVoQCgtNdWJ/LiD67W2O7sdVSGinbV mvQAniz4mbJr3+8pzYj0siG5v+jjj+Ko =SB5Q -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
