> > > > 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
This should be a separate discussion. But, I would think the
counters will be n_aggressive, n_wraparound and n_failsafe.
We need to separate aggressive and wraparound due to
what is mentioned in vacuumlazy.c
/*
* While it's possible for a VACUUM to be both is_wraparound
* and !aggressive, that's just a corner-case -- is_wraparound
* implies aggressive. Produce distinct output for the corner
* case all the same, just in case.
*/
A normal vacuum is the difference of autovacuum_count and the
total of these counters.
--
Sami Imseih
Amazon Web Services (AWS)
