You make a argument for Bloatware. It is not oersuasive. JS Roger Binns wrote: > -----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
_______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
