Re: Configuring PostgreSQL to minimize impact of checkpoints

Jan Wieck <JanWieck(at)Yahoo(dot)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