Jan Wieck <JanWieck@Yahoo.com> writes:
> If we would combine the background writer and the checkpointer,
... which in fact is on my agenda of things to do ...
> then a
> "checkpoint flush" could actually be implemented as a temporary change
> in that activity that basically is done by not reevaluating the list of
> to be flushed blocks any more and switching to a constant amount of
> blocks flushed per cycle. When that list get's empty, the checkpoint
> flush is done, the checkpoint can complete and the background writer
> resumes normal business.
Sounds like a plan. I'll do it that way. However, we might want to
have different configuration settings controlling the write rate during
checkpoint and the rate during normal background writing --- what do you
think?
Also, presumably a shutdown checkpoint should just whomp out the data
without any delays. We can't afford to wait around and risk having
init decide we took too long.
>> None of this is necessarily going to fix matters for an installation
>> that has no spare I/O capacity, though.
> As a matter of fact, the background writer increases the overall IO. It
> writes buffers that possibly get modified again before a checkpoint or
> their replacement requires them to be finally written. So if there is no
> spare IO bandwidth, it makes things worse.
Right, the trickle writes could be wasted effort.
regards, tom lane