| From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
|---|---|
| To: | Ken Kato <katouknl(at)oss(dot)nttdata(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Subject: | Re: Add last_vacuum_index_scans in pg_stat_all_tables |
| Date: | 2022-09-16 05:52:20 |
| Message-ID: | bc26e96b-181f-060d-b13c-ff5588d6d386@oss.nttdata.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2022-09-16 06:00:31 | Re: [PoC] Improve dead tuple storage for lazy vacuum |
| Previous Message | Amit Kapila | 2022-09-16 05:42:29 | Re: why can't a table be part of the same publication as its schema |