Re: More vacuum stats

On Mon, Aug 23, 2010 at 16:28, Greg Smith <greg@2ndquadrant.com> wrote:
> Tom Lane wrote:
>>
>> So I'd like to see a positive argument why this is important for users
>> to know, rather than merely "we should expose every conceivable detail
>> by default".  Why wouldn't a user care more about last AV time for a
>> specific table, which we already do expose?
>>
>
> What I actually want here is for the time that the last table autovacuum
> started, adding to the finish time currently exposed by pg_stat_user_tables.
>  "How long did the last {auto}vacuum on <x> take to run?" is a FAQ on busy
> systems here.  If I could compute that from a pair of columns, it's a major
> step toward answering even more interesting questions like "how does this
> set of cost delay parameters turn into an approximate MB/s worth of
> processing rate on my tables?".  This is too important of a difficult tuning
> exercise to leave to log scraping forever.

Now, that would be quite useful. That'd require another stats message,
since we don't send anything on autovacuum start, but I don't think
the overhead of that is anything we need to worry about - in
comparison to an actual vacuum...

Do we want that for both vacuum and autovacuum? vacuum and analyze?

We could also store last_autovacuum_vacuum_duration - is that better
or worse than start and end time?


> I'd rather have that and look at for "SELECT max(last_autovacuum_start) FROM
> pg_stat_user_tables" to diagnose the sort of problems this patch seems to
> aim at helping.

Agreed. Consider this patch withdrawn.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/