-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Stanton wrote: > Perhaps this featrure could be reserved for "Sqlheavy", a replacement > for Oracle.
Or a #if OMIT_STATEMENT_CACHE like all sorts of other functionality that can be omitted. > We have actually implemented the cacheing of prepared statements, and > add it in the form of a local library which extends the Sqlite API. If almost everyone is doing a statement cache then there is a stronger argument for it being part of the core library. > Cacheing compiled SQL is only helpful in certain types of application. I'd argue that it is helpful in most applications that use bindings and don't implement their own statement caching. > In a typical emdedded application where all SQL is compiled as the > application intializes and subsequent usage involves the binding of > variables cacheing would be detrimental to performance and footprint. Caching would increase memory for one off queries since unused statements would be in the cache. In your scenario there would actually be no difference since the cache would be empty. A SQLite hash table with no entries is approximately 28 bytes. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkV6qIACgkQmOOfHg372QTsOgCggRTY1TSkxHLznv95G64N+PjH p34AoMHMjgGsxZTgufEVUz7hP6uM8/14 =0HbU -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
