Re: BUG #15245: pg_stat_all_tables does not include partition mastertables
От | Michael Paquier |
---|---|
Тема | Re: BUG #15245: pg_stat_all_tables does not include partition mastertables |
Дата | |
Msg-id | 20180618124943.GB1721@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #15245: pg_stat_all_tables does not include partition mastertables (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: BUG #15245: pg_stat_all_tables does not include partition mastertables
|
Список | pgsql-bugs |
On Mon, Jun 18, 2018 at 07:21:17PM +0900, Amit Langote wrote: > I'm not sure of the vacuum (maybe NULL's the answer in that case), but if > we ever teach autovacuum the ability to *analyze* partitioned tables, then > we could simply record the time when that happens, instead of worrying > about how to aggregate across partitions. We could leave that NULL for > now, that is, if we decide to list partitioned tables in the > pg_stat_all_tables output at all re OP's complaint. Even for the last_* columns, it is not really possible to have one single definition for the partition parents. Here are a set of stats which could be useful depending on the context: - average of the last runs. - deviation of the last runs. - Latest one which ran. - Oldest one which ran. The same applies for the tuples inserted and/or deleted, scans, etc. Users may want to know the deviation to check for the balance across partitions, or the sum of them, or even the average. For those reasons having entries in pg_stat_all_tables or such for parent partitions has little meaning, and having something which allows to grab a complete partition tree has way more value because it becomes easier to gather stats about the whole tree. -- Michael
Вложения
В списке pgsql-bugs по дате отправления: