Hello Taras, List, I have been fighting the same problems described here for a long time, and have no real elegant solution. So, the proposed solution of the OP below would be ideal for me too. The proposed pragma could also define a number of pages to be allocated at once instead of a number of bytes.
In my case, the database grows continously and the file is often extremely fragmented when the growth phase is finished (this concerns the file on the disk, not internal fragmentation) Currently, i monitor the size of the database using pragma freelist_count. When I see the value of free pages approach zero, i create a dummy table with a blob field and fill it with a very large empty blob. Then i drop the table. The empty pages remain behind and page_count does not rise any more for a time. This has been proposed to me on this list a while ago. However, testing the database in this way and creating and dropping the table carries a performance penalty, and finding the strategic places in my application to do this has been difficult. Martin Am 23.07.2010 03:11, schrieb Taras Glek: <snip> > Seems like the > easiest fix here is to add a pragma fs_allocation_size. It would > preallocate a continuous chunk of diskspace. Sqlite would behave exactly > as it does now, except it would avoid truncating the file beyond a > multiple of the fs_allocation_size. > For example, pragma fs_allocation_size=50M would grow the db file to > 50megabytes. Once the db grows to beyond 50mb the underlying file would > get resized to 100mb. <snip> _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
