Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Greg Stark wrote:
>> Put another way, we already have such a clock scan, it's called checkpoint.
>> You could have checkpoint delay between each page write long enough to spread
>> the checkpoint i/o out over a configurable amount of time -- say half the
>> checkpoint interval -- and be done with that side of things.
> But don't you have to keep the WAL files around longer then.
Yeah, but do you care? It seems like what Greg is suggesting is a
"checkpoint slowdown" knob comparable to the "vacuum slowdown"
feature that Jan added for 8.0. It strikes me as not necessarily
a bad idea.
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.
Shutdown checkpoints would still need to go as fast as possible,
so we might need two separate code paths; or maybe we could just
change the delay setting locally during a shutdown.
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.
regards, tom lane
