Re: Displaying accumulated autovacuum cost

On Thu, Aug 18, 2011 at 17:54, Greg Smith <greg(at)2ndquadrant(dot)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/