On Mon, 19 May 2014 20:35:54 -0400 Richard Hipp <d...@sqlite.org> wrote:
> > > On 19 May 2014, at 10:21pm, Roger Binns <rog...@rogerbinns.com> > > > wrote: > > > > > > > It seems like most language wrappers for SQLite include some > > > > sort of statement cache because it is generally useful. It > > > > seems like the sort of thing that would be helpful within the > > > > core of SQLite itself, or as an officially supported extra > > > > extension. > > > > > > Are there any advantages to this other than increased speed ? > > > > I'm going to go out on a limb and say No, > > > The cache is very useful when you want to execute a query like the > following 1 million times, with different bindings each time. > > INSERT INTO tab1 VALUES($a, $b, $c); Are we talking about the same thing? You're talking about using one prepared statement repeatedly, which, if nothing else, is convenient. And the application can always maintain its "cache" of prepared-statement handles. Whether the prepare step actually saves much relative to an INSERT is not obvious to me. On a machine that can execute, say, 25,000 INSERTs per second, wouldn't you expect at least 100X that number of prepares? 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. While I have your ear, though, do you have any rule-of-thumb about query compilation time? --jkl _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
