Re: another autovacuum scheduling thread

Jeremy Schneider <schneider@ardentperf.com>

From: Jeremy Schneider <schneider@ardentperf.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Robert Treat <rob@xzilla.net>, David Rowley <dgrowleyml@gmail.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2025-11-12T23:51:13Z
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 Nov 12, 2025, at 5:10 PM, Sami Imseih <samimseih@gmail.com> wrote:
> 
> 
>> 
>> I do think re-prioritization is worth considering, but IMHO we should leave
>> it out of phase 1.  I think it's pretty easy to reason about one round of
>> prioritization being okay.  The order is completely arbitrary today, so how
>> could ordering by vacuum-related criteria make things any worse?
> 
> While it’s true that the current table order is arbitrary, that arbitrariness
> naturally helps distribute vacuum work across tables of various sizes
> at a given time
> 
> The proposal now is by design forcing all the top bloated table, that
> will require more I/O to vacuum to be vacuumed at the same time,
> by all workers. Users may observe this after they upgrade and wonder
> why their I/O profile changed and perhaps slowed others non-vacuum
> related processing down. They also don't have a knob to go back to
> the previous behavior.
> 
> Of course, this behavior can and will happen now, but with this
> prioritization, we are forcing it.
> 
> Is this a concern?

It’s still possible to tune the cost delay, the number of autovacuum workers, etc - if someone needs to manage too much autovacuum I/O concurrency and dialing it back down a little bit. I think that’s sufficient

-Jeremy