Naoya Anzai <nao-an...@xc.jp.nec.com> writes: > In my much experience up until now,I have an idea that we can add > 2 new vacuum statistics into pg_stat_xxx_tables.
Adding new stats in that way requires adding per-table counters, which bloat the statistics files (especially in database with very many tables). I do not think you've made a case for these stats being valuable enough to justify such overhead for everybody. As far as the first one goes, I don't even think it's especially useful. There might be value in tracking the times of the last few vacuums on a table, but knowing the time for only the latest one doesn't sound like it would prove much. So I'd be inclined to think more along the lines of scanning the postmaster log for autovacuum runtimes, instead of squeezing it into the pg_stats views. A possible alternative so far as the second one goes is to add a function (perhaps in contrib/pg_freespacemap) that simply runs through a table's VM and counts the number of set bits. This would be more accurate (no risk of lost counter updates) and very possibly cheaper overall: it would take longer to find out the number when you wanted it, but you wouldn't be paying the distributed overhead of tracking it when you didn't want it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers