On Thu, Oct 02, 2003 at 05:31:52AM -0700, Seun Osewa wrote:
>
> The beauty of the scheme is that the WAL syncs which "sync everyone's
> changes so far" would cost about the same as the WAL syncs for just
> one transaction being committed. But when there are so many trans-
> actions we would not have to sync the WAL so often.
In that case, why not go to a "lazy" policy in high-load situations,
where subsequent commits are bundled up into a single physical write?
Just hold up a commit until either there's a full buffer's worth of
commits waiting to be written, or some timer says it's time to flush
so the client doesn't wait too long.
It would increase per-client latency when viewed in isolation, but if
it really improves throughput that much you might end up getting a
faster response after all.
(BTW I haven't looked at the code involved so this may be completely
wrong, impossible, and/or how it works already)
Jeroen
