MIME-Version: 1.0
References: <abMR6MQGQyyKWep4@nathan>
 <CAApHDvqHXYCb=x0hHeR1e21ksqFNk4q3_zoPk6V-LLu0VL491Q@mail.gmail.com>
 <abrOO8GCgkhMXvcq@nathan>
 <bff7dc5a-f839-449b-b56a-aab36cd3e39d@app.fastmail.com>
 <CAApHDvpnR5zKb7LSB0idj4RPsV+=Dhtk+c5H0cZ4evN2hFDwCQ@mail.gmail.com>
 <3ca1e398-c787-47e9-9afc-8e298b94dac0@app.fastmail.com>
 <abwbDTu6OO6Izp4o@nathan>
 <CAA5RZ0s7k6yve1Bq1OY+aXU3ifc_fvOiYkpE2VxwrUcHr2AtTg@mail.gmail.com>
 <CAApHDvpvkKYB6z-i1kiO9iePF0fz18-CaS9DZEWnSx1eO0RGFQ@mail.gmail.com>
 <CAA5RZ0tPvWLVXhDMC3t3LhwTM-OnWHSvPo7tnZzOphR=HB4kgQ@mail.gmail.com>
 <ab2uoj5yU8CVUJ_H@nathan>
In-Reply-To: <ab2uoj5yU8CVUJ_H@nathan>
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: Sat, 21 Mar 2026 17:08:56 -0700
Message-ID: 
 <CALj2ACV0HboeYiT1Z-=rb509WL3N0H9LsWRPqc_xUMEM-TM85g@mail.gmail.com>
Subject: Re: another autovacuum scheduling thread
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>, David Rowley <dgrowleyml@gmail.com>,
 Greg Burd <greg@burd.me>,
	Robert Haas <robertmhaas@gmail.com>, Robert Treat <rob@xzilla.net>,
	Jeremy Schneider <schneider@ardentperf.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/CALj2ACV0HboeYiT1Z-%3Drb509WL3N0H9LsWRPqc_xUMEM-TM85g%40mail.gmail.com>
Precedence: bulk

On Fri, Mar 20, 2026 at 1:31=E2=80=AFPM Nathan Bossart <nathandbossart@gmai=
l.com> wrote:
>
> Thanks for the feedback.  Here is an updated patch.
>
> I kept the comment about the weight parameters in autovacuum.c.  Since
> there's a bunch of code related to them, IMHO we should have an explanato=
ry
> note somewhere.

Hi Nathan, Thank you for working on this feature. I'm late to this
thread. I read the patch, and here are some general thoughts. I
haven't read the full thread, so some of these thoughts may be
repetitive - thanks for bearing with me.

1/ The Autovacuum Prioritization section in the docs is a good start
for explaining the usage aspects of the new scoring system. However,
IMHO, adding a couple of production-like scenarios showing how these
scores need to be adjusted and used would be a good addition to this
section.

2/ Any plans to extend the new scoring system to the table level
(i.e., reloptions)? I think it would help in situations where there
are huge tables that need to be prioritized for vacuum over others, so
setting the scoring high for those tables would allow the next
autovacuum to pick them up first.

3/ Any plans to add tests to demo how each of these parameters could
help in various situations - when the system needs freezing to be
prioritized for avoiding XID wraparound over cleaning up dead tuples,
and when it needs analyze to be prioritized to get correct plans,
etc.? If needed, we could add elog(DEBUGX) messages to emit the reason
or effectiveness of these new scores so that we can verify them in
tests.

4/ Is adding a reason (such as how each of these scores influenced the
autovacuum to pick this table) to vacuum progress reporting a good
idea? This helps answer some of the why and how questions when the
autovacuum is in progress.

--=20
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com