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/