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.
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.
-- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
