On Thu, Aug 18, 2011 at 17:54, Greg Smith <g...@2ndquadrant.com> wrote: > 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.
The "current values per-backend" thing can go in shared memory. The reason the per table ones can't is obviously that they go away when the backend disconnects.. > 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. That depends on what you mea nby too wide. If it's intended to be consumed with "SELECT *" or not... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers