> While backwards compatibility is important, there’s definitely precedent for > changing > what shows up in the catalog. IMHO it’s better to bite the bullet and move > those fields > instead of having vacuum stats spread across two different views.
Correct, the most recent one that I could think of is pg_stat_checkpointer, which pulled the checkpoint related columns from pg_stat_bgwriter. In that case though, these are distinct background processes and it's a clear distinction. In this case, I am not so sure about this, particularly because we will then have the autoanalyze and autovacuum fields in different views, which could be more confusing to users than saying pg_stat_all_tables has high level metrics about vacuum and analyze and for more details on vacuum, refer to pg_stat_vacuum_tables ( or whatever name we settle on ). Regards, Sami
