On Mon, Aug 23, 2010 at 16:28, Greg Smith <g...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers