On 08/18/2011 10:54 AM, Peter Eisentraut wrote:
So how about adding a column to pg_stat_activity, progress_metrics or
something like that, and add that information there.

Adding a field here (I'd go for the simpler "progress") and updating it regularly would be a reasonable way to go here. This data doesn't really need to go into the traditional statistics infrastructure to be useful. I didn't start there because I was already getting pushback on overloading the stats collector with constantly updated metrics last time I did something in this area. I wasn't going to try and argue why it was worth it in this case, just like I'm not going to argue about the complaint over the command string overhead being too high--just going to not do that instead. If the bikeshed I built doesn't look fancy enough to hold the bike I put in there, I'm not going to build a better one right now--I'll just put a cheaper bike in there instead.

I was hoping to eventually take the useful summary bits at the end, the totals, and save those into statistics somewhere each time a VACUUM of either sort finishes. It would fit with the information shown in pg_stat_tables, but that's obviously getting too wide. Breaking out a pg_stat_autovacuum view that contains all the relevant bits currently shown in that view, plus these 3 new fields, would be a reasonable start.

--
Greg Smith   2ndQuadrant US    g...@2ndquadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to