Whenever you start a new transaction, SQLite has to
allocate and clear a bitmap used to record which
pages have changes in the database file.  The size
of this bitmap is proportional to the size of the
database file.  The size of the bitmap is 256 bytes
per megabyte of database file assuming a 1KiB page
size.  That translates into about 52MB for a 200GiB
database.  This is doable, but probably not optimal.

Methods for reducing the memory requirements of this
bitmap (so that it is proportional to the size of the
change rather than the size of the database) have been
proposed, but we have not taken any steps toward
implementing them since the current approach works
well enough. But as people start to push SQLite into the 100GiB size and beyond, we will likely revisit
that decision.


How was the current default page size of 1K determined? Was there any testing to see if larger page sizes would be beneficial for general use? Or is it just a historical circumstance (i.e. an arbitrarily chosen value that has been maintained for backwards compatability)?

I'm thinking the "usual" case may be changing as available storage gets larger, and users start storing more and larger BLOBs in the database.

Dennis Cote

To unsubscribe, send email to [EMAIL PROTECTED]

Reply via email to