MIME-Version: 1.0
References: <adB9nSsm_S0D9708@nathan>
In-Reply-To: <adB9nSsm_S0D9708@nathan>
From: Robert Treat <rob@xzilla.net>
Date: Sat, 4 Apr 2026 07:53:21 -0400
Message-ID: 
 <CAJSLCQ3JqDfHju2FcaMb0G3Q1m+-G5Sg_6r071CMkNZm5hOdGw@mail.gmail.com>
Subject: Re: remove autoanalyze corner case
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
 satyanarlapuram@gmail.com,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAJSLCQ3JqDfHju2FcaMb0G3Q1m%2B-G5Sg_6r071CMkNZm5hOdGw%40mail.gmail.com>
Precedence: bulk

On Fri, Apr 3, 2026 at 10:55=E2=80=AFPM Nathan Bossart <nathandbossart@gmai=
l.com> wrote:
>
> (new thread from [0])
>
> On Fri, Apr 03, 2026 at 02:13:16PM -0500, Sami Imseih wrote:
> >> * I noticed that if autovacuum decides to force a vacuum for
> >> anti-wraparound purposes, it might also decide to analyze the table ev=
en if
> >> autovacuum is disabled for it.  AFAICT this is accidental, but since i=
t's
> >> behaved this way since commit 48188e1621 (2006) [0], I am slightly wor=
ried
> >> that this bug may have become a feature.  In 0002, I separated this ed=
ge
> >> case in the code and added a comment, and I intend to start a new thre=
ad
> >> about removing it.
> >
> > hmm yeah, I think this just needs to be documented clearly. I always
> > thought it was expected for auto-analyze to run in this case, and I don=
't
> > see why it shouldn't. If this needs to be clarified in docs, we should
> > do that in a separate discussion.
>
> Well, autoanalyze only runs in this case if autovacuum is disabled via th=
e
> table's autovacuum_enabled reloption and _not_ disabled via the autovacuu=
m
> or track_counts GUCs.  I think this is pretty clearly unintentional, as I
> can find no mention in the code, archives, or docs.  And unless I'm missi=
ng
> something, it's completely unnecessary.  So IMHO we should just remove it=
.
>
> [0] https://postgr.es/m/CAA5RZ0sCRjH3xkHFdSXnKysdMZXFyaS_094%2BK-O_rr4Fkm=
wc%3DQ%40mail.gmail.com
>

AFAICS, near misses on wraparound in and of itself have no correlation
with statistical changes in your data, so I'd agree it isn't
necessary, and the fact that it behaves differently in this more
narrow case than it would in the more general case, when these two
cases are (as far as I've ever known) supposed to behave the same way,
I'd be +1 to remove this.

Robert Treat
https://xzilla.net