ITAGAKI Takahiro wrote: > 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?
Sorry, I meant bgwriter delay, not autovauum. > 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. OK. > > 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. Ah, OK, so we already reserve a full set of WAL files while we are waiting for the checkpoint to complete. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
