Greg Stark <gsstark@mit.edu> writes:
> The question should be why is there any time when a checkpoint *isn't*
> happening? For maximum performance the combination of bgwriter (basically
> preemptive checkpoint i/o) and the actual checkpoint i/o should be executing
> at a more or less even pace throughout the time interval between checkpoints.
I think Josh's complaint has to do with the fact that performance
remains visibly affected after the checkpoint is over. (It'd be nice
if those TPM graphs could be marked with the actual checkpoint begin
and end instants, so we could confirm or deny that we are looking at a
post-checkpoint recovery curve and not some very weird behavior inside
the checkpoint.) It's certainly true that tuning the bgwriter ought to
help in reducing the amount of I/O done by a checkpoint, but why is
there a persistent effect?
> That said, does checkpointing (and bgwriter i/o) require rereading the WAL
> logs?
No. In fact, the WAL is never read at all, except during actual
post-crash recovery.
regards, tom lane
