Re: another autovacuum scheduling thread

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Jeremy Schneider <schneider@ardentperf.com>, pgsql-hackers@postgresql.org
Date: 2025-11-11T20:13:44Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add rudimentary table prioritization to autovacuum.

  2. Trigger more frequent autovacuums with relallfrozen

  3. Harden nbtree page deletion.

  4. Check for interrupts inside the nbtree page deletion code.

On Wed, Nov 12, 2025 at 09:03:54AM +1300, David Rowley wrote:
> I'm still trying to work out what Sami sees in the results that he
> doesn't think is good. I resuggested he try coding up the periodic
> refresh-the-list code to see if it makes the thing he sees better. I
> was hoping that we could get away with not doing that for stage 1 of
> this. My concern there is that these change-the-way-autovacuum-works
> patches seems to blow up quickly as everyone chips in with autovacuum
> problems they want fixed and expect the patch to do it all.

+1

> That said, the periodic refresh probably isn't too hard. I suspected
> it was something like:
> 
>      /* when enough time has passed, refresh the list to ensure the
> scores aren't too out-of-date */
>     if (time is > lastcheck + autovacuum_naptime * <something>)
>     {
>         list_free_deep(tables_to_process);
>        goto the_top;
>     }
> } // end of foreach(cell, tables_to_process)

My concern is that this might add already-processed tables back to the
list, so a worker might never be able to clear it.  Maybe that's not a real
problem in practice for some reason, but it does feel like a step too far
for stage 1, as you said above.

-- 
nathan