On Jun 1, 2011 1:46 PM, "Jan Hudec" <b...@ucw.cz> wrote: > On Tue, May 31, 2011 at 16:44:13 -0500, Nico Williams wrote: > > On Tue, May 31, 2011 at 4:22 PM, Simon Slavin <slav...@bigfraud.org> wrote: > > > Split the DROP into two stages: > > > > > > DELETE FROM myTable; > > > DROP TABLE myTable; > > > > > > Which one takes all the time ? If it's the second one, then perhaps just delete all the records. Filling the table back up again with new rows obviously already takes considerable time so adding extra time may not be as inconvenient. > > The first one alone takes more time than the drop alone did before (already > tried some time ago).
Delete might require visiting all the leaf nodes as well (even when doing a delete with no WHERE clause). > > That's gonna have the same problem: in order to find out what pages to > > add to the free list the engine will have to traverse the interior > > nodes of the table's b-tree. > > > > You could rename the table and then delete from ... order by rowid asc > > limit 1000, to delete 1000 rows at a time. Add in incremental > > autovacuum and that might do the trick. > > The autovacuum would just add more work reshuffling the data around. And > it's not that the pages are going to be unused long. But you've not tried it, right? You don't need the autovacuum unless you're concerned about storage consumption anyways. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
