I use auto-vacuum in my application storage for work. This was introduced in about 2013.
The motivation was more political than anything though, as convincing some as to the introduction requiring jumping through some pretty arbitrary hoops. Enabling auto-vacuum was one of those, to mitigate concerns that a piece of software unused in the immediate development centre would chew up resources needed by other more business critical processes. On Tue, 14 Feb 2017 at 07:14 Richard Hipp <d...@sqlite.org> wrote: > On 2/13/17, Scott Hess <sh...@google.com> wrote: > > > > Below is a patch which implements [PRAGMA auto_vacuum_slack_pages = N]. > > This setting allows client code to signal that auto_vacuum can leave > pages > > on the freelist until releasing them would allow a db size change. > > This makes me want to ask: Is anybody still using auto_vacuum? And > if they are, should they be? > > Auto-vacuum was invented way back in 2004, for Motorola, who at the > time was the worlds leading manufacturer of mobile phones. This was > during the heyday of flip-phones, before iPhone or Android. The > devices had very little flash memory - total storage capacity was > measured in megabytes rather than gigabytes. If storage ran low, > Motorola wanted to be able to VACUUM the SQLite databases to make them > smaller. The problem there is VACUUM requires nearly 2x the size of > the original database in temp storage, so if you are already low on > space, VACUUM probably won't work. The solution was auto-vacuum, > which keeps the databases at near their minimum size at all times, at > the cost of some extra database fragmentation, more I/O, and reduced > performance. > > Fast foward 13 years (how long is that in internet-years?) and the > situation has changed. Does anybody really care anymore that a > database file might have a few dozen pages on its freelist? Or if > they do care, does anybody lack the temp space sufficient to run a > real VACUUM? My impression is that these days people just want the > database to run fast and with a minimum of I/O and are not overly > concerned with a few extra freelist pages, which means that > auto-vacuum should remain turned off. > > Scott: The motivation for your patch seem to be to get auto-vacuum to > run a little faster. But if performance is your goal, why not just > turn auto-vacuum off? Or, failing that, set it to INCREMENTAL and > then run "PRAGMA incremental_vacuum" when "PRAGMA freelist_count" > reaches some threshold? > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
