I'll add the results from additional tests. First of all, I forced a commit after each 100,000 records inserted into a single table. (A complication for us.)
Some numbers for a table with a single index and 3,423,000 inserted records: Intermediate commits took subsequently 764 msec, 2164 msec, 4462... 38532 msec. In other words the commit time more or less regularly increased. I attribute this to the index building. Total time spent in all commits is 730 secs. Index rebuild (using sqlite3 shell) took 123 sec. This would suggest that it might be better to run with deleted indexes and rebuild them at the end. WAL size started at 65MB and slightly increased once upon a time ending finally at 177MB. Very good. DB size increased by roughly 17-18K after each commit. This suggests that WAL needs 10x more memory than the DB itself. Other large tables yielded similar results as above. I made one additional observation worth of reporting. After an hour or so the debugger (not the application) stopped working leaving thus active WAL. Running SELECT COUNT(*) on currently processed table took 44 secs. However, after the WAL was commited, the same select took 2 secs. -- View this message in context: http://sqlite.1065341.n5.nabble.com/Huge-WAL-log-tp79991p80024.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
