On Wed, 11 Jan 2006, Tom Lane wrote:
> Qingqing Zhou <zhouqq@cs.toronto.edu> writes:
> > So I wonder is it possible flush only dirty buffers with LSN < RedoRecPtr
> > to improve checkpoint caused delay?
>
> Certainly not. If LSN > RedoRecPtr then you know the buffer contains
> some changes more recent than the checkpoint, but you cannot tell
> whether it also contains changes older than the checkpoint. For
> correctness you must flush it.
>
Right.
> It'd be possible to do something like this: after establishing
> RedoRecPtr, make one quick pass through the buffers and make a list of
> what needs to be dumped at that instant. Then go back and do the actual
> I/O for only those buffers. I'm dubious that this will really improve
> matters though, as the net effect is just to postpone I/O that will
> happen anyway soon after the checkpoint (as soon as the bgwriter goes
> back to normal activity).
>
Looks like a good idea. I don't worry too much about the problem you
mentioned. AFAIK, checkpoint has two targets: (1) cleanup buffer pool; (2)
reduce recovery time;
For (2), it is clear that the above idea will work since the recovery will
always read the data page to check its LSN -- the is the source of the
cost. For (1), we have bgwriter, and part of reason it is desiged is to
cleanup buffer pool.
On a separate matter, it will be interesting to add a io-status-dector in
bgwriter to make it know when the disk is free so a cleanup is valuable.
Regards,
Qingqing