MIME-Version: 1.0
References: <ac2ODZSOjWNzueHZ@nathan>
 <CAA5RZ0uVg0L3vVvkOiHaY9ZJ+K9ZcsyQH0TVQ5rXSd-ZEeVFNg@mail.gmail.com>
 <ac_vLKVgs4RYK1P-@nathan>
 <CAA5RZ0sCRjH3xkHFdSXnKysdMZXFyaS_094+K-O_rr4Fkmwc=Q@mail.gmail.com>
 <adB6FQeoUst6gHA0@nathan>
 <CAA5RZ0t6bCR6Pasd_eWqXvyUmrNDWmHUy1yN_Po-c4+b9BtBqQ@mail.gmail.com>
 <adEhRzu4YM7ztLXr@nathan>
 <CAA5RZ0vxby2osMMaCuZ=680tmt583cF9n4rOzTGdsiS-1PJknA@mail.gmail.com>
 <adE9RbcA7lhH_w2d@nathan>
 <CAA5RZ0tYzPDeXbqz9uKacRV2xjD055qrg=s3w2PEQPK8EruuSg@mail.gmail.com>
 <adFiCgN22xJ7Z-oR@nathan>
In-Reply-To: <adFiCgN22xJ7Z-oR@nathan>
From: Sami Imseih <samimseih@gmail.com>
Date: Sat, 4 Apr 2026 17:35:50 -0500
Message-ID: 
 <CAA5RZ0vRP-W2wJD2OxEb-=VGj2sp5pMCqHQg9YJiuDVPhaY5jQ@mail.gmail.com>
Subject: Re: Add pg_stat_autovacuum_priority
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
 Robert Treat <rob@xzilla.net>,
	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/CAA5RZ0vRP-W2wJD2OxEb-%3DVGj2sp5pMCqHQg9YJiuDVPhaY5jQ%40mail.gmail.com>
Precedence: bulk

> >> If we did report booleans, I would probably argue for just reporting
> >> dovacuum and doanalyze and calling out the criteria for why they may b=
e
> >> false even when it looks like the table needs processing.
> >
> > Yes, we only require a needs_analyze and needs_vacuum. The latter
> > can be set to true due to thresholds or wraparound. But, I don't think =
we
> > should rely on the dovacuum or doanalyze, instead we can just have a fl=
ag
> > in AutoVacuumScores->needs and track what is needed. This will separate
> > the autovacuum processing from the reporting.
>
> Sorry for going in circles about this, but I'm not seeing why we wouldn't
> just return the booleans that relation_needs_vacanalyze() already returns=
.
> I think the question people will have is "what will autovacuum process an=
d
> in what order?", and if we aren't giving them the exact same information
> that autovacuum is using to make its decisions, then I'm not sure what is
> the point.  It's true that someone might disable autovacuum for a table a=
nd
> that it would otherwise be processed, but so be it.

Maybe there=E2=80=99s no need to worry too much about the autovacuum disabl=
ed
case or track_counts being disabled when querying the view. Both are
edge cases, and it seemed fairly trivial to compensate for this with what
I had attached earlier. Anyhow, I will not push this point further. I am ok
with proceeding with what you have in v12. The patches overall LGTM.

Thanks!

--
Sami