Gregory Stark <stark@enterprisedb.com> writes:
> How does all of this relate to your epiphany that we should just have
> bgwriter be a full clock sweep ahead clock hand without retracing its
> steps?
Well, it's still clearly silly for the bgwriter to rescan buffers it's
already cleaned. But I think we've established that the "keep a lap
ahead" idea goes too far, because it writes dirty buffers speculatively,
long before they actually are needed, and there's just too much chance
of the writes being wasted due to re-dirtying. When proposing that
idea I had supposed that wasted writes wouldn't hurt much, but that's
evidently wrong.
Heikki makes a good point nearby that if you are not disk write
bottlenecked then it's perfectly OK for backends to issue writes,
as it'll just result in a transfer to kernel cache space, and no actual
wait for I/O. And if you *are* write-bottlenecked, then the last thing
you want is any wasted writes. So a fairly conservative strategy that
does bgwrites only "just in time" seems like what we need to aim at.
I think the moving-average-of-requests idea, with a user-adjustable
scaling factor, is the best we have at the moment.
regards, tom lane