MIME-Version: 1.0
References: 
 <CAA5RZ0tPvWLVXhDMC3t3LhwTM-OnWHSvPo7tnZzOphR=HB4kgQ@mail.gmail.com>
 <ab2uoj5yU8CVUJ_H@nathan>
 <CALj2ACV0HboeYiT1Z-=rb509WL3N0H9LsWRPqc_xUMEM-TM85g@mail.gmail.com>
 <acFan6knPZljm1Ay@nathan>
 <CAA5RZ0tz55uoQfcvLwvRWRPM0ry6SGfZ=-enQ4F0kaUgfPh+Vg@mail.gmail.com>
 <acGqIhkP6xo4Vv1l@nathan>
 <CAMFBP2q-oMzpEua9Hdcpag15VGZn7aEO-uaHZ4yVEO_HCm55_Q@mail.gmail.com>
 <CAApHDvqQN-B2sQov8nsfZOmx-VeJMauSf4kLa3A8LsK1tUyBNw@mail.gmail.com>
 <acLGoktU2lp4SIlU@nathan>
 <CALj2ACUTuHZugAgbDk-NNPY_CPbw+c4T=HkRvvqq-FKqnVb24A@mail.gmail.com>
 <acRROBvlokDLQZlh@nathan>
In-Reply-To: <acRROBvlokDLQZlh@nathan>
From: David Rowley <dgrowleyml@gmail.com>
Date: Thu, 26 Mar 2026 11:00:24 +1300
Message-ID: 
 <CAApHDvrD9YZ8RBgb6NDtzyay1PsFReLvWHVqUCMFw1=qxM1N1g@mail.gmail.com>
Subject: Re: another autovacuum scheduling thread
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
 Jim Nasby <jnasby@upgrade.com>,
	Sami Imseih <samimseih@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"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvrD9YZ8RBgb6NDtzyay1PsFReLvWHVqUCMFw1%3DqxM1N1g%40mail.gmail.com>
Precedence: bulk

On Thu, 26 Mar 2026 at 10:18, Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> On Wed, Mar 25, 2026 at 02:12:16PM -0700, Bharath Rupireddy wrote:
> > Would it make sense to recompute scores and re-sort the remaining
> > table list after each table is processed in do_autovacuum()'s main
> > loop - say, after a certain amount of time spent vacuuming the large
> > table(s)? This would catch the above scenarios. I see that the scores
> > per table are being calculated in relation_needs_vacanalyze, but they
> > are ignored in the recheck path (table_recheck_autovac ->
> > recheck_relation_needs_vacanalyze -> relation_needs_vacanalyze).
>
> I think this was discussed a bit upthread, and we decided to leave it out
> for now.  But things like reprioritization and automatic cost limit
> adjustments seem worth considering for v20.

Agreed. I think the reason you mentioned in [1] was a good reason not
to do this.

There are also other autovacuum workers that may be calculating a more
up-to-date list. They may well process the table that's increased
score before the worker with the slightly stale list makes it there.
That seems fine and natural to me.

David

[1] https://postgr.es/m/aROY-MUVO_mYTl2f%40nathan