Re: another autovacuum scheduling thread

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Jim Nasby <jnasby(at)upgrade(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, Greg Burd <greg(at)burd(dot)me>, Robert Haas <robertmhaas(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: another autovacuum scheduling thread
Date: 2026-03-25 22:00:24
Message-ID: CAApHDvrD9YZ8RBgb6NDtzyay1PsFReLvWHVqUCMFw1=qxM1N1g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 26 Mar 2026 at 10:18, Nathan Bossart <nathandbossart(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2026-03-25 22:06:14 Re: LockHasWaiters() crashes on fast-path locks
Previous Message Andres Freund 2026-03-25 21:58:46 Re: Don't synchronously wait for already-in-progress IO in read stream