On 8 Dec 2014, at 12:43am, David Barrett <dbarr...@expensify.com> wrote:
> Other alternatives we're considering are to fork and nice the process, or > to call ioprio_set() directly, but I'm curious if there's a simpler way to > do it. Thanks! VACUUM does the same job (in a very different way) as copying all the TABLEs, then creating the VIEWS, INDEXes and TRIGGERs on the new tables. These can all be done using SQL statements. Had you considered creating a VACUUMed copy yourself ? You could do one table/view/index/trigger at a time. And you could engineer a pause of a few seconds after every ten thousand rows are put in a table. But I'm wondering why you need to VACUUM often enough that anything it does is a problem. It can save filespace after deletion (before new data is put in to take up the released filespace), and it can increase speed, but the speed increase is small. It's not needed in normal use. It should be kept for a maintenance routine, perhaps once a month at most. If your users are putting in more data than they are deleting, VACUUM has no noticable effect and I know of SQLite databases which have been amended daily for years without ever once having been VACUUMed. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
