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 Sent with inky<http://inky.com?kme=signature> "Simon Slavin" <slavins at bigfraud.org> wrote: On 17 Feb 2016, at 3:34pm, Simon Slavin <slavins at bigfraud.org> wrote: > A lot of operations on the database file are done at the beginning and end of > every transaction. If your journal is in memory, then you can dramatically > disk usage by using large transactions. So I think you are right and you > should check out that strategy. I'm sorry, that's poorly phrased and has a word missing. Here's a better version: A high proportion of the disk activity involved in making changes to the database are done to support the transaction structure, rather than the individual operation (INSERT/UPDATE/DELETE) you asked for. Grouping lots of operations together into one transaction will reduce the overhead needed for locking and ACID. In addition, in some journal modes operations relating to the transaction as a whole are done with the database file whereas much of the work relating to the operations is done with the journal file. This should increase the advantage in your situation gained by using large transactions. Simon. _______________________________________________ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users