On 2015/12/10 20:46, Michael Paquier wrote: > On Thu, Dec 10, 2015 at 7:23 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> AIUI, the counts published via stats collector are updated asynchronously >> w.r.t. operations they count and mostly as aggregate figures. For example, >> PgStat_StatTabEntry.blocks_fetched. IOW, we never see >> pg_statio_all_tables.heap_blks_read updating as a scan reads blocks. Maybe >> that helps keep traffic to pgstat collector to sane levels. But that is >> not to mean that I think controlling stats collector levels was the only >> design consideration behind how such counters are published. >> >> In case of reporting counters as progress info, it seems we might have to >> send too many PgStat_Msg's, for example, for every block we finish >> processing during vacuum. That kind of message traffic may swamp the >> collector. Then we need to see the updated counters from other counters in >> near real-time though that may be possible with suitable (build?) >> configuration. > > 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. 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
