Bruce Momjian <[EMAIL PROTECTED]> wrote: > OK, if I understand correctly, instead of doing a buffer scan, write(), > and fsync(), and recyle the WAL files at checkpoint time, you delay the > scan/write part with the some delay.
Exactly. Actual behavior of checkpoint is not changed by the patch. Compared with existing checkpoints, it just takes longer time in scan/write part. > Do you use the same delay autovacuum uses? What do you mean 'the same delay'? Autovacuum does VACUUM, not CHECKPOINT. If you think cost-based-delay, I think we cannot use it here. It's hard to estimate how much checkpoints delay by cost-based sleeping, but we should finish asynchronous checkpoints by the start of next checkpoint. So I gave priority to punctuality over load smoothing. > As I remember, often the checkpoint is caused because > we are using the last WAL file. Doesn't this delay the creation of new > WAL files by renaming the old ones to higher numbers (we can't rename > them until the checkpoint is complete)? Checkpoints should be done by the next one, so we need WAL files for two checkpoints. It is the same as now. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq