Re: Checkpoint question
От
Tom Lane
Тема
Re: Checkpoint question
Дата
Msg-id
406.1137035575@sss.pgh.pa.us
Ответ на
Checkpoint question (Qingqing Zhou)
Список
Дерево обсуждения
Checkpoint question Qingqing Zhou <zhouqq@cs.toronto.edu>
Re: Checkpoint question Simon Riggs <simon@2ndquadrant.com>
Re: Checkpoint question Qingqing Zhou <zhouqq@cs.toronto.edu>
Re: Checkpoint question Simon Riggs <simon@2ndquadrant.com>
Re: Checkpoint question Tom Lane <tgl@sss.pgh.pa.us>
Re: Checkpoint question Qingqing Zhou <zhouqq@cs.toronto.edu>
Re: Checkpoint question Simon Riggs <simon@2ndquadrant.com>
Re: Checkpoint question Tom Lane <tgl@sss.pgh.pa.us>
Re: Checkpoint question Qingqing Zhou <zhouqq@cs.toronto.edu>
Re: Checkpoint question "Jim C. Nasby" <jnasby@pervasive.com>
Re: Checkpoint question Qingqing Zhou <zhouqq@cs.toronto.edu>
Re: Checkpoint question "Jim C. Nasby" <jnasby@pervasive.com>
Re: Checkpoint question Qingqing Zhou <zhouqq@cs.toronto.edu>
Qingqing Zhou 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. 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). regards, tom lane
В списке pgsql-hackers по дате отправления