Tom Lane <tgl@sss.pgh.pa.us> writes:
> Suppose that you run a checkpoint every 5 minutes, and with the knob
> you slow down the checkpoint to extend over say 3 minutes on average,
> rather than the normal blast-it-out-as-fast-as-possible. Then you'll
> be keeping an average of 8 minutes worth of WAL files instead of 5.
> Not exactly a killer objection.
Right. I was thinking that the goal would be to spread the checkpoint out over
exactly the checkpoint interval, minus some safety factor. So if it has some
estimate of the total number of dirty buffers that need flushing it could just
divide the checkpoint interval by that and calculate the delay needed to
finish in some fraction of the checkpoint interval, 60% seems like a
reasonable guess.
> One issue is that while we can regulate the rate at which we issue
> write()s, we still have to issue fsync()s at the end, and we can't
> control what happens in response to those. It's quite possible that
> all the I/O would happen in response to the fsync()s anyway, in which
> case the whole exercise would be a waste of time.
Well you could fsync earlier as well, say just before whenever you sleep.
Obviously the delay on the checkpoint process doesn't matter to performance if
it's about to sleep. It could end up scheduling i/o earlier than necessary and
cause redundant seeks but then I guess that's an inherent tension between
trying to spread out the i/o evenly and trying to get the ideal ordering of
i/o.
--
greg