Re: Add mode column to pg_stat_progress_vacuum - Mailing list pgsql-hackers

From Shinya Kato
Subject Re: Add mode column to pg_stat_progress_vacuum
Date
Msg-id CAOzEurTq_72iBiinfyswXkda9ARm_xkASXHVyKV-EZFLmVU=-g@mail.gmail.com
Whole thread Raw
In response to Re: Add mode column to pg_stat_progress_vacuum  (Sami Imseih <samimseih@gmail.com>)
Responses Re: Add mode column to pg_stat_progress_vacuum
List pgsql-hackers
On Wed, Oct 8, 2025 at 4:40 AM Sami Imseih <samimseih@gmail.com> wrote:
>
> > >  I wonder if we could be even more granular
> > > for the "normal autovacuum" case and point to the reason the table was
> > > chosen.  For example, was it the insert threshold, the update/delete
> > > threshold, etc.?
> >
> > Sounds like reasonable information. I guess we might want to have such
> > information in a cumulative statistics view but do you think it's
> > better to have it in a dynamic statistics view?
>
> +1 for this information in cumulative stats, on a per table level for sure.
> I do think however the pg_stat_all_tables views is getting too wide
> and moving new relation vacuum stats to a separate stats view will
> be very useful.

Thanks for the discussion.

IIUC are you suggesting I add such a last_autovacuum_reason column to
pg_stat_all_tables, which would be populated with one of the following
values?
- autovacuum_vacuum_threshold
- autovacuum_vacuum_insert_threshold
- autovacuum_freeze_max_age
- autovacuum_multixact_freeze_max_age

(For consistency, I should probably add  a last_autoanalyze_reason
column to pg_stat_all_tables as well.)

--
Best regards,
Shinya Kato
NTT OSS Center



pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: VACUUM (PARALLEL) option processing not using DefElem the way it was intended
Next
From: Robert Haas
Date:
Subject: Re: Should we update the random_page_cost default value?