Rowan Worth-2 wrote > The entire point of SQL transactions is to implement this magic!
I beg to differ; you proposed: > (1) BEGIN TRANSACTION > > (2) DROP all indexes from the table This is by no means valid SQL semantics; in all RDBBMS I've worked with, structure changes' relation to a transaction is undefined at best. Even if it works now, there's no guarantee the "BEGIN; DROP" behavior will be consistent any time in the future. So in repect to this, the alternative of copying to a different table, TRUNCATE, copy back, looks much more semantically acceptable. Rowan Worth-2 wrote > WAL has different concurrency characteristics. Yeap, it's supposed to do just this, keep readers from starving until a write is complete; the WAL flush works quite well it seems, keeping the HDD at a respectable 100% and so the WAL flush will take less than 30s. Populating the table, on the other hand, takes much longer. -- Sent from: http://sqlite.1065341.n5.nabble.com/ _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
