My reading of the code has the readers flushing their cache often, and
not using the journal at all to maintain consistency. My reading has the reader start with nothing in the cache, lock the database with a read lock, perform as many SQL queries as are in the single text string it's currently parsing, and flush its cache around the time it unlocks the database.
So if the cache is thrown away after every transaction, does that mean that if I do "select * from mytable" twice in a row (in different transactions), that there will be the same number of read() system calls for the second one? Even if there are no intervening changes? That hardly seems optimal, even within the constraints of the sqlite architecture.....
Yes, that is what it means.
You can make it reuse the cache by putting both SELECTs inside a BEGIN...COMMIT. But in so doing, you limit yourself to a single reader.
I have run experiments to see how much faster SQLite might work if it didn't invalidate its cache so quickly. The answer is about 15%. So it is probably worth looking into someday. Note that such a change will be backwards but not forwards compatible. Suppose this change happened for version 2.9.0. Then a 2.9.0 library would be able to read and write a 2.8.13 database file, but a 2.8.13 library would not be able to read and write a 2.9.0 database file. Such a change it not to be made lightly and without careful consideration.
-- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
