On Fri, Aug 30, 2013 at 3:52 PM, Simon Slavin <slav...@bigfraud.org> wrote:
> Great question. If all you are doing is writing (never any UPDATE or > DELETE FROM or DROP) then VACUUM won't save any space in your database > file. It would defragment your database and might thereby increase speed a > little, but this is mostly for old-fashioned systems that get most of their > speed from 'read-ahead buffering'. I would not expect much of a time > saving (less than 1%) from any modern setup (test it !). If it's > difficult, annoying or time-consuming to do the VACUUM I wouldn't bother. > This has not been my experience. I have a legacy system that exports data by writing it to a sqlite database. This file is only ever written to once (not updated or deleted while being written, either), vacuumed, zipped and sent to a receiving system. The file size varies greatly, based on the source data. The database schema has ~20 tables in it, some with many rows, some with very few. There are a few indices (created with the schema, before the data is populated). Vacuuming the database file shrinks it between 10% and 20%. This surprised me; I was expecting near zero savings. However, I did not research why, I just accepted it and moved on. I suggest to the OP to perform some experiments. That is what I did. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
