Re: Add last_vacuum_index_scans in pg_stat_all_tables

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Add last_vacuum_index_scans in pg_stat_all_tables
Дата
Msg-id bc26e96b-181f-060d-b13c-ff5588d6d386@oss.nttdata.com
обсуждение исходный текст
Ответ на Re: 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  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers

On 2022/09/16 13:23, Ken Kato wrote:
>> Regression is failing on all platforms; please correct that and
>> resubmit the patch.
> 
> Hi,
> 
> Thank you for the review!
> I fixed it and resubmitting the patch.

Could you tell me why the number of index scans should be tracked for
each table? Instead, isn't it enough to have one global counter, to
check whether the current setting of maintenance_work_mem is sufficient
or not? That is, I'm thinking to have something like pg_stat_vacuum view
that reports, for example, the number of vacuum runs, the total
number of index scans, the maximum number of index scans by one
vacuum run, the number of cancellation of vacuum because of
lock conflicts, etc. If so, when these global counters are high or
increasing, we can think that it may worth tuning maintenance_work_mem.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: why can't a table be part of the same publication as its schema
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [PoC] Improve dead tuple storage for lazy vacuum