> It's never time to VACUUM a database. This is an interesting statement. In our application, all tables get heavily fragmented with time (99% or more). I was considering VACUUM as a means to defragment, and, presumably, improve search performance. Was I misguided, and search performance does not degrade significantly with the increased fragmentation of the DB?
(I guess it well might not on an SSD disk, but on a conventional rotational disk, pager could read several pages ahead with one seek - but does it?) It would be great to see performance comparison, if anyone has ever did it. -- Igor On Wed, Jul 7, 2010 at 1:52 AM, Simon Slavin <[email protected]> wrote: > > On 6 Jul 2010, at 10:45pm, Kristoffer Danielsson wrote: > >> Q: How do I programmatically (through sqlite-APIs?) determine if it's time >> to VACUUM a database? > > It's never time to VACUUM a database. The VACUUM command is useful only if > you have want to recover unused space from the database file. So if your > database file once took up 5 Meg, and you deleted a lot of data from it and > it now takes up only 2 Meg, you could recover 3 Megabytes of disk space. But > how useful is that 3 Megabytes of space to you ? Are you going to use it for > something really valuable ? And how long will it be before you get 3 > Megabytes more data which will fill it up again ? > > If you're trying to get the database in shape to make copies, e.g. to burn it > on a DVD or send it to customers, or put it on a device with limited space, > then there might be some reason to use VACUUM. If not, then it's just a > waste of resources. > > Simon. > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
