Re: Vacuum statistics
От | Jim Nasby |
---|---|
Тема | Re: Vacuum statistics |
Дата | |
Msg-id | E806AFB8-168A-4396-BFA8-F3CF52B7AE3F@upgrade.com обсуждение исходный текст |
Ответ на | Re: Vacuum statistics (Sami Imseih <samimseih@gmail.com>) |
Ответы |
Re: Vacuum statistics
|
Список | pgsql-hackers |
On Jan 2, 2025, at 4:33 PM, Sami Imseih <samimseih@gmail.com> wrote: > >> 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 ). I guess one question is how realistic it is to try and put everything about (auto)vacuum in a single view. Given the complexity,the answer to that might just be “no”. In that case leaving existing fields in pg_stat_all_tables is a lot morereasonable. Related to this… it’d be nice if we had a view that gave insight to users about auto vacuum scheduling. I know there’s onefloating around the internet, but given the number of systems I’ve seen where autovac can’t keep up it’d be good to raiseuser awareness.
В списке pgsql-hackers по дате отправления: