Would not that be more efficient to do it in batch? Like an entry in transaction means a block of deletions? If there is a crash during dropping operation then the journal can be looked up and replayed.
Pi Song On Wed, Mar 18, 2009 at 12:05 PM, Jim Wilcoxson <pri...@gmail.com> wrote: > Drop is executed within a transaction, which means that every record > you touch has to be backed up to the journal first, then modified in > the database. I'm guessing that if you use pragma synchronous=off, it > would speed up the drop index, but you'd take a chance on corrupting > the database if the machine crashed during the drop. > > It would probably be faster to make a copy of the database (all > sequential I/O), then drop the index with synchronous=off in one of > the copies (no journal I/O), then use vacuum if you want to really > clean up the DB. If something goes wrong, you still have your backup > copy. > > I haven't actually tried this; let us know if it makes a big difference. > > Jim > > On 3/17/09, Nikolas Stevenson-Molnar <steve...@evergreen.edu> wrote: >> Hi, >> >> I'm trying to drop an index on a table with about 8 million rows and >> it's taking a very long time. I can understand why building the index >> would take some time, but why dropping it? And is there any way to >> speed it up? >> >> Thanks! >> _Nik >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > > > -- > Software first. Software lasts! > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
