In regards to WAL (write-ahead-logging) support being added to SQLite for 
version 3.7.0, I have a few comments, questions, suggestions, etc.  Most of 
them 
refer to parts of http://www.sqlite.org/draft/wal.html .

1.  Congratulations on this move, which should greatly improve SQLite's utility 
relative to 3.6.x.  I greatly look forward to the multi-versioning capabilities 
that this would provide.

2.  Quoth the raven:

     "The wal-index greatly improves the performance of readers, but the use of 
shared memory means that all readers must exist on the same machine.  This is 
why the write-ahead log implementation will not work on a network filesystem."

I don't understand the need to sacrifice WAL on a network filesystem.  My naive 
interpretation of the situation is that WAL itself would work on a network 
filesystem, but just that processes using it that way would have slower 
performance as they can't use the wal-index.

I would think it better that WAL *is* supported on the network but with the 
caveat that its performance would be slower than use by a process on the same 
machine.  Then even network users can still get the multi-versioning/etc 
benefits but just slower read performance.  And concurrent processes on the 
same 
machine as the database would still use the wal-index at the same time.

Is there more to this that I'm not seeing, or could SQLite's WAL be altered as 
I 
suggest above so that network users are supported but just more slowly?

3.  Quoth the raven:

     "A checkpoint operation takes all the content from the WAL file and 
transfers it back into the original database file. As long as all readers are 
looking at the entire WAL file (in other words, as long as no reader is using 
an 
end mark that is earlier than the actual end of the WAL) then it will be OK for 
the checkpoint to run in parallel with the readers.  []  Thus, a checkpoint 
will 
never block a reader and readers will not block a checkpoint as long as all 
readers are looking at the entire WAL. But, older readers that only see a 
prefix 
of the WAL will block a checkpoint.  []"

I don't understand the need for checkpointing to be an all-or-none affair.  If 
not all readers are looking at the entire WAL file, then why can't just a 
subset 
of the WAL be checkpointed, that subset corresponding to what the reader sees 
that started the earliest so that then the WAL only has the corresponding 
subset 
from the earliest reader to the latest?

-- Darren Duncan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to