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.


> > 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]

  + 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

Reply via email to