On 2 Září 2011, 19:09, Robert Haas wrote:
> On Thu, Sep 1, 2011 at 3:59 PM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
>> I've prepared a significantly simplified version of the patch. The two
>> main changes are
>> (a) it does not update the pg_stat_bgwriter anymore, it just prints an
>> info to the server log
>> (b) a new GUC is not required, it's driven by the log_checkpoints
>> This version will log at least 10 'checkpoint status' lines (at 10%,
>> 30%, ...) and whenever 5 seconds since the last log elapses. The time is
>> not checked for each buffer but for 128 buffers.
>> So if the checkpoint is very slow, you'll get a message every 5 seconds,
>> if it's fast you'll get 10 messages.
> This seems like a strange heuristic. I understand the value of
> emitting a progress report every N seconds, but why would you want a
> report at 10%, 20%, 30% even if it hasn't been 5 seconds yet? I don't
> need ten progress messages on a checkpoint that only takes three
> seconds to complete.
Not really, but I admit that the current heuristics is a bit weird.
I do need to get info about progress even for timed checkpoints (that's
why I'm logging after each 10%). OTOH I've just realized that with the
current implementation it'll log each 5 seconds, so for a 5-minute timed
checkpoint you'll get about 60 messages. That probably is too much,
especially if you're using completion target near 1.0 (which means there's
always a timed checkpoint running).
So I think a sane heuristics would be:
(1) for a timed checpoint, log each 10%
(2) for other checkpoint types, log after 5 seconds
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2011-09-02 18:54:07|
|Subject: Re: sha1, sha2 functions into core?|
|Previous:||From: Tom Lane||Date: 2011-09-02 18:52:25|
|Subject: Re: WAL "low watermark" during base backup |