On 2015/12/11 14:41, Kyotaro HORIGUCHI wrote: > Sorry, I misunderstood the meaning of PgStat_*.
I should've just said "messages to the stats collector" instead of "PgStat_Msg's". > > At Fri, 11 Dec 2015 09:41:04 +0900, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote >>> As far as I understand it, the basic reason why this patch exists is >>> to allow a DBA to have a hint of the progress of a VACUUM that may be >>> taking minutes, or say hours, which is something we don't have now. So >>> it seems perfectly fine to me to report this information >>> asynchronously with a bit of lag. Why would we need so much precision >>> in the report? >> >> Sorry, I didn't mean to overstate this requirement. I agree precise >> real-time reporting of progress info is not such a stringent requirement >> from the patch. The point regarding whether we should storm the collector >> with progress info messages still holds, IMHO. > > Taking a few seconds interval between each messages would be > sufficient. I personaly think that gettimeofday() per processing > every buffer (or few buffers) is not so heavy-weight but I > suppose there's not such a consensus here. However, > IsCheckpointOnSchedule does that per writing one buffer. > > vacuum_delay_point() seems to be a reasonable point to check the > interval and send stats since it would be designed to be called > with the interval also appropriate for this purpose. Interesting, vacuum_delay_point() may be worth considering. It seems though that, overall, PgBackendStatus approach may be more suited for progress tracking. Let's see what the author thinks. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers