On Tue, 2008-09-09 at 12:54 +0300, Heikki Linnakangas wrote:
> Note that we already have the logic to flush all pending commit
> records at once.
But only when you can grab WALInsertLock when flushing. If you look at
the way I suggested, it does not rely upon that lock being available.
So it is both responsive in low write rate conditions and yet efficient
in high write rate conditions and does not require we specify a wait
time.
IMHO the idea of a wait time is a confusion that comes from using a
simple example (with respect). If we imagine the example slightly
differently you'll see a different answer:
High write rate: A stream of commits come so fast that by the time a
write completes there are always > 1 backends waiting to commit again.
In that case, there is never any need to wait because the arrival
pattern requries us to issues writes as quickly as we can.
Medium write rate: Commits occur relatively frequently, so that the mean
commits/flush is in the range 0.5 - 1. In this case, we can get better
I/O efficiency by introducing waits. But note that a wait is risky, and
at some point we may wait without another commit arriving. In this case,
if the disk can keep up with the write rate, why would we want to
improve I/O efficiency? There's no a priori way of calculating a useful
wait time, so waiting is always a risk. Why would we risk damage to our
response times when the disk can keep up with write rate?
So for me, introducing a wait is something you might want to consider in
medium rate conditions. Anything more or less than that and a wait is
useless. So optimising for the case where the arrival rate is within a
certain fairly tight range seems not worthwhile.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
