Re: Add last_vacuum_index_scans in pg_stat_all_tables
От | Alvaro Herrera |
---|---|
Тема | Re: Add last_vacuum_index_scans in pg_stat_all_tables |
Дата | |
Msg-id | 20220708164052.bp62uhma56v7u7n5@alvherre.pgsql обсуждение исходный текст |
Ответ на | Add last_vacuum_index_scans in pg_stat_all_tables (Ken Kato <katouknl@oss.nttdata.com>) |
Ответы |
Re: Add last_vacuum_index_scans in pg_stat_all_tables
|
Список | pgsql-hackers |
On 2022-Jul-04, Ken Kato wrote: > I think having number of index scans of the last vacuum in > pg_stat_all_tables can be helpful. This value shows how efficiently vacuums > have performed and can be an indicator to increase maintenance_work_mem. Yeah, this would be a good metric to expose, since it directly tells how to set autovacuum_work_mem. I'm not sure that the shape you propose is correct, though, because each vacuum run would clobber whatever value was there before. No other stats counter works that way; they are all additive. But I'm not sure that adding the current number each time is sensible, either, because then the only thing you know is the average of the last X runs, which doesn't tell you much. Saving some sort of history would be much more useful, but of course a lot more work. > It was proposed previously[1], but it was not accepted due to the limitation > of stats collector. Statistics are now stored in shared memory, so we got > more rooms to store statistics. I think this statistics is still valuable > for some people, so I am proposing this again. > [1] https://www.postgresql.org/message-id/20171010.192616.108347483.horiguchi.kyotaro%40lab.ntt.co.jp I read this thread, but what was proposed there is a bunch of metrics that are not this one. The discussions there centered about how it would be unacceptable to incur in the space cost that would be taken by adding autovacuum-related metrics completely different from the one you propose. That debate is now over, so we're clear to proceed. But we need to agree on what to add. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
В списке pgsql-hackers по дате отправления: