From: | Sami Imseih <samimseih(at)gmail(dot)com> |
---|---|
To: | Robert Treat <rob(at)xzilla(dot)net> |
Cc: | Shayon Mukherjee <shayonj(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Prolonged truncation phase during vacuum on toast table with repeated interruptions by lock waiters and a proposed POC patch |
Date: | 2025-05-08 18:56:55 |
Message-ID: | CAA5RZ0v5CGxaCyNnHxc=Sd8=9it+xqGRZTzYQ17tm2Q7Z1R0qA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> actually determine you are in this situation, or how bad the situation
> was, in order to know that setting truncate off would help? To that
Adding counters for this area is not a bad idea in general, as this hits
customers particularly hard on hot standbys when the truncate does actually
occur on the primary.
What about adding cumulative counters ( per table and pg_stat_database
) such as:
pages_vac_truncated - # of pages truncated by vacuum
vac_truncate_conflicts - # of time truncate was skipped due to conflict
vac_truncate_suspended - # of times the truncate was suspended.
The difference between conflict and suspended is conflict causes vacuum
to skip the truncate phase while suspended causes vacuum to retry the
phase continually.
The argument against adding these counters is that the views,
pg_stat_all_tables/
pg_stat_all_database are becoming super-wide, so maybe we need to think
about inventing a new view for vacuum related counter metrics. This seems like
a good discussion for v19.
--
Sami
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2025-05-08 19:11:07 | Re: pgsql: Make cancel request keys longer |
Previous Message | Robert Treat | 2025-05-08 18:23:28 | Re: Prolonged truncation phase during vacuum on toast table with repeated interruptions by lock waiters and a proposed POC patch |