Jan Wieck <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org