On Thu, Aug 18, 2011 at 17:54, Greg Smith <greg@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/