From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Displaying accumulated autovacuum cost |
Date: | 2011-08-18 16:00:22 |
Message-ID: | CABUevEznfZfhBK0twdSRnMYCD4RYHS1ZTS3CCkzo1q1E3y0EAg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-08-18 16:46:17 | Re: [v9.1] sepgsql - userspace access vector cache |
Previous Message | Greg Smith | 2011-08-18 15:54:50 | Re: Displaying accumulated autovacuum cost |