Re: obsolete autovacuum comment

On Wed, Nov 12, 2025 at 09:52:49AM +1300, David Rowley wrote:
> I've never been able to make sense of that comment. I tried to dig a
> bit yesterday and still couldn't make sense of it in the context of
> the commit when it was added. I assume it's talking about
> pg_stat_all_tables.autovacuum_count, but I can't think why that
> matters as I didn't find any code that took that into account for
> triggering autovacuum.

pg_autovacuum used to have this:

/* If the stats collector is reporting fewer updates then we have on record
then the stats were probably reset, so we need to reset also */
if ((tbl->curr_analyze_count < tbl->CountAtLastAnalyze) ||
(tbl->curr_vacuum_count < tbl->CountAtLastVacuum))
{
tbl->CountAtLastAnalyze = tbl->curr_analyze_count;
tbl->CountAtLastVacuum = tbl->curr_vacuum_count;
}

I think this was translated to the following in earlier versions of the
autovacuum patch:

+ /*
+ * Consider stat-reset: if the differences are negative, reset the
+ * last-seen counters.
+ *
+ * It's OK if tab->operation is rewritten later to VacuumAnalyze or
+ * Analyze, because these operations take care of updating
+ * pg_autovacuum as needed.
+ *
+ * We reset the counters to 0, not their current value, because that's
+ * what stat-reset did reset them to. So we will operate on them
+ * closer to the reality (this is like saying they were last vacuumed
+ * at the same time the stat-reset happened.) Also use these numbers
+ * to determine whether to vacuum on this iteration.
+ */
+ if (vactuples - avForm->vac_last_cnt < 0)
+ {
+ tab->operation = AVOperUpdateCounts;
+ tab->reltuples = 0;
+ tab->update_vactuples = true;
+ vac_last_cnt = 0;
+ }
+ else
+ vac_last_cnt = avForm->vac_last_cnt;

This stuff seems to have been ultimately replaced with the comment in
question. AFAICT that was briefly discussed here [0]. So, my
interpretation is that this was referring a separately maintained "last
count" of the number of updated/deleted tuples for the table, which was
abandoned in favor of keeping track of the number of dead tuples in the
stats system. But I'm not super confident in this analysis.

[0] https://postgr.es/m/20050712233455.GB15464%40alvh.no-ip.org

--
nathan