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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly