Bruce Momjian <bruce@momjian.us> 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