On Jan 5, 2015, at 5:03 PM, Eduardo Morras <emorr...@yahoo.es> wrote:
> On Mon, 5 Jan 2015 14:42:28 -0600 > Jay Kreibich <j...@kreibi.ch> wrote: > >> >> >> On Jan 5, 2015, at 12:25 PM, Jim Wilcoxson <pri...@gmail.com> wrote: >> >>> Simon - instead of using vacuum, it's much faster to create a new >>> database from the old one, then rename it. It's easy to do this in >>> Python using iterdump(), or you can connect to the new (empty) >>> database, do your create table statements, attach the old database >>> as olddb, then do: >>> >>> insert into table1 select * from olddb.table1; >>> insert into table2 select 8 from olddb.table2; >>> >>> This also lets you do the create table stmts w/o indexes, and add >>> the indexes after the inserts. Not sure if that is faster or not >>> for your data. >> >> If you look at code for VACUUM, that’s more or less what it does… >> only it is very smart about it, properly preserving ROWID values, as >> well as exact table definitions, sequences, analytics, and all the >> meta-data in the database. > > Sqlite3 Backup API should work too, and covers your vacuum to file proposal. No, the backup API does a page-by-page copy. It’s goal is to make a bit-perfect copy of the original database file. It makes no attempt to VACUUM the database as it is backed-up, and has no understanding of the data it is copying. The backup-API does not remove empty space or re-order pages, nor does it allow changes to database page size and other alterations supported by VACUUM. The backup API also operates outside the SQL transaction system. VACUUM TO would be a simplified version of VACUUM that only requires 2x the disk space (rather than 3x) and much, much less I/O (possibly 1/3 or so). It would be faster for many applications that control all access to a database, such as applications that use SQLite DBs as their document file format. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
