On Fri, Oct 22, 2010 at 2:54 PM, Bob Smith <[email protected]> wrote:
> What I have determined (via using sqlite3_wal_hook, catching some > statistics > in the callback as well as calling sqlite3_wal_checkpoint from the callback > myself) is that each time I am writing during a read operation (so a > checkpoint can't complete), I am able to write more records than the last > time on average during this period. So, more records written during the > time > a checkpoint can't happen is going to relate to the WAL file needing to > grow. > .... > I am not sure why more writes are progressively able to occur each time > these reads are happening, but this is the cause of my continued WAL file > growth in this scenario. > On many (most?) filesystems, it is faster to overwrite an existing area of a file than it is to extend the file by writing past the end. That's why SQLite doesn't truncate the WAL file on each checkpoint - so that subsequent writes will be overwriting an existing file region and thus go faster. So apparently, as long as you are overwriting existing parts of the WAL, the writes go faster and you quickly get to the end of the WAL where writes start to slow down. But the WAL got a little bigger so more writes go fast on the next cycle, and the WAL grows a little more. And so forth. Is that what you are seeing? Which filesystem are you using? -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
