On 26 Srpen 2011, 0:39, Tomas Vondra wrote:
> On 26 Srpen 2011, 0:18, Josh Berkus wrote:
>> Tomas,
>>
>>> I'd like to propose a small patch that allows better checkpoint
>>> progress
>>> monitoring. The patch is quite simple - it adds a new integer GUC
>>> "checkpoint_update_limit" and every time checkpoint writes this number
>>> of
>>> buffers, it does two things:
>>
>> I'd rather not have a new GUC if we can avoid it. What about just
>> making this some reasonable value (like 1000 buffers) if log_checkpoints
>> = on?
>
> I was thinking about that too, but I think no value can fit all cases
> because the systems may have very different I/O subsystems.
>
> With one 7.2k drive I usually get about 25MB/s on average, with big arrays
> / good controllers / fast drives you can write much faster. So either the
> value will be too low (and the log will be infested with those messages)
> or too high (so it won't be updated very often).
Hmmm, maybe we could use time instead of number of buffers? Something like
"every 5 seconds, log the checkpoint progress" instead of "every time 1000
buffers is written ..."
That should work on systems regardless of I/O performance.
But although using time instead of number of buffers seems like a good
idea, I don't think it eliminates the need for a new GUC.
(a) Even with time limit, I find it useful to be able to set the limits
differently.
(b) In some cases it may be useful to enable just basic (current
behaviour) checkpoint logging using log_checkpoints, so using it for this
new patch may not be a good idea. Although this could be fixed by allowing
three values no/basic/detailed instead of just true/false.
Tomas