Doug Currie wrote:
Using the OS or RAID may solve many problems. In this case, though, I
proposed a solution that eliminated all of the index journaling
normally applied by sqlite. In D. Richard Hipp's example there were
30000 writes to (mostly) different pages for idx2. With sqlite
presently this means 60000 pages written, and a lot of disk head
motion. With my approach, it means 30001 pages written (lazily) -- and
it works without added hardware or a journaling file system.
Now, I'm not necessarily advocating changing sqlite in this way, but I
don't think you'll see this > 2::1 speed advantage with just OS
journaling.
Your suggestion was to reconstruct the index from original
table data on a rollback. For a large transaction that touches
most pages of the index, this can give (at best) a 2:1 speedup.
But the other side, the potential slowdown is extreme. In the
case of a transaction that touches a single page of the index
then rolls back, all 30000 pages of the index must be reconstructed
instead of just resetting a single page. So you can easily get
a 30000:1 slowdown or worse. Furthermore, the case of touching
one or two pages then rolling back is fairly common, in my
experience. So I'm thinking I don't want to make a change that
will have a huge negative impact on the performance of rollbacks.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
