On 2 Září 2011, 19:09, Robert Haas wrote: > On Thu, Sep 1, 2011 at 3:59 PM, Tomas Vondra <t...@fuzzy.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%, >> 20%, >> 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 Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
