Hi, Thanks for the work you have done here. Exposing cumulative metrics at this level of detail for vacuum is surely useful to find vacuum bottlenecks and to determine the effectiveness of vacuum tuning.
I am yet to look very closely, but I think some additional columns that will be useful is the number of failsafe autovacuums occurred. Also the counter for number of index_cleanup skipped, truncate phase skipped and toast vacuuming skipped ( the latter will only be relevant for the main relation ). I also wonder if if makes sense to break down timing by phase. I surely would like to know how much of my vacuum time was spent in index cleanup vs heap scan, etc. A nit: I noticed in v14, the column is "schema". It should be "schemaname" for consistency. Also, instead of pg_stat_vacuum_tables, what about pg_stat_vacuum? Now, I became aware of this discussion after starting a new thread to track total time spent in vacuum/analyze in pg_stat_all_tables [1]. But this begs the question of what should be done with the current counters in pg_stat_all_tables? I see it mentioned above that (auto)vacuum_count should be added to this new view, but it's also already in pg_stat_all_tables. I don't think we should be duplicating the same columns across views. I think total_time should be removed from your current patch and added as is being suggested in [1]. This way high level metrics such as counts and total time spent remain in pg_stat_all_tables, while the new view you are proposing will contain more details. I don't think we will have consistency issues between the views because a reset using pg_stat_reset() will act on all the stats and pg_stat_reset_single_table_counters() will act on all the stats related to that table. There should be no way to reset the vacuum stats independently, AFAICT. Alternatively, we can remove the vacuum related stats from pg_stat_all_tables, but that will break monitoring tools and will leave us with the (auto)analyze metrics alone in pg_stat_all_tables. This sounds very ugly. What do you think? Regards, Sami Imseih Amazon Web Services (AWS) [1] https://commitfest.postgresql.org/52/5485/
