> > On Wed, Mar 25, 2026 at 01:28:47AM +0900, Yugo Nagata wrote: > > > Although the timestamps are overwritten on each skipped autovacuum or > > > autoanalyze, they still indicate when the last attempt was made. This > > > can help users confirm that autovacuum is actively attempting to run, > > > and that the issue is due to repeated skips rather than inactivity. > > > > > > While counters can indicate overall activity, they do not reveal when > > > the last skip occurred. With timestamps, users can immediately see the > > > most recent attempt, even without a separate dashboard or historical > > > tracking. > > > > > > Therefore, counters are useful for monitoring overall activity, but > > > timestamps give additional, complementary information, so it seems > > > worthwhile to include them too. > > > > Hmm.. I can buy this argument for the timestamps, especially for > > database with many relations of various sizes that could take a > > various amount of time to process. The timestamps could offer hints > > about the time it takes between the skips, even if snapshots of the > > stats data are not taken at a very aggressive frequency.
I'm fine with adding timestamps, as there seem to be convincing reasons to add them. My other concern is bloat of the pg_stat_all_tables view. This patch adds 4 columns, or 8 if we also include manual vacuum and analyze (which I think we should). Given that, should we also start thinking about splitting the vacuum activity related columns into a dedicated view and out of pg_stat_all_tables for v20? -- Sami Imseih Amazon Web Services (AWS)
