Re: obsolete autovacuum comment

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: obsolete autovacuum comment
Date: 2025-11-12 17:09:40
Message-ID: 202511121645.gyp5n6va56qf@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025-Nov-10, Nathan Bossart wrote:

> While working on my autovacuum scheduling patch [0], I noticed the
> following comment in relation_needs_vacanalyze():
>
> /*
> * Note that we don't need to take special consideration for stat
> * reset, because if that happens, the last vacuum and analyze counts
> * will be reset too.
> */
>
> AFAICT this is a relic from pg_autovacuum (the contrib module and
> predecessor to modern autovacuum) [1] and early versions of the autovacuum
> patch [2] [3].

Hmm, I think it's yes and no. contrib/pg_autovacuum, as introduced in
commit bd18c50ba87f [1], includes the comment about stats reset when
considering whether to vacuum or analyze:

+ /* 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((numInserts < tbl->InsertsAtLastAnalyze)||(numDeletes < tbl->DeletesAtLastVacuum))
+ {
+ tbl->InsertsAtLastAnalyze=numInserts;
+ tbl->DeletesAtLastVacuum=numDeletes;
+ }

The comment you cite appears more or less in the same place in
autovacuum-6.patch (the routine was called test_rel_for_autovac there),
but I think what it really is about, is the AVOperUpdateCounts operation
that was in autovacuum-5.patch. Note that that older patch was
introducing a new pg_autovacuum catalog which kept track of tuple counts
since last analyze/vacuum, and those counts needed to be updated in case
pgstats was reset. But by patch autovacuum-6.patch this had disappeared
(the counts were now in pgstats, per review from Tom), so we didn't need
to reset any counters, and the AVOperUpdateCounts operation went away.

It's quite possible that, having removed the "counter reset" operation
from the proposed patch and reduced the comment to what we have today,
we promptly forgot about the whole thing. So the comment is indeed a
relic that can be removed.

Thanks,

[1] https://postgr.es/c/bd18c50ba87f12d1dc0aa65c1ff0507b2d1c5c41

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"La fuerza no está en los medios físicos
sino que reside en una voluntad indomable" (Gandhi)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-11-12 17:11:36 Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Previous Message Bertrand Drouvot 2025-11-12 17:03:55 Re: relfilenode statistics