Clarification to my own post: When I talk about buffering, say, 16MB of write transactions in memory, I want the effects transactions to be visible to readers immediately (once they are "commited" to RAM). This seems akin to WAL mode where SQLite scans the .wal file prior to scanning the .dat file on SELECTs.
(BTW, I'm using WAL mode and have found it performs better than standard journal mode on pretty much every target device.) Dave Sent with inky<http://inky.com?kme=signature> "Dave Baggett" <dmb at inky.com> wrote: OK, that helps -- thank you. One clarification: is it the case that transaction bundling ONLY affects write/delete operations -- i.e., those operations that alter the database? Another clarification: is it the case that writes within a single transaction will remain in the in-memory page cache until COMMIT is issued? I see various pragmas like cache_spill that seem to control the page cache but I'm confused as to what they do. Finally, is there a way to tell SQLite I would like to buffer, say, 16MB of write/delete transactions in memory before the transactions are written to disk? Here I am talking about the meta level above the transaction level -- I have atomic transactions and I want to defer physically writing them until I have enough of them (say, 16MB worth of altered pages). Dave
