Horton

Re: another autovacuum scheduling thread

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>, Nathan Bossart <nathandbossart@gmail.com>, Robert Treat <rob@xzilla.net>, Jeremy Schneider <schneider@ardentperf.com>, pgsql-hackers@postgresql.org
Date: 2025-11-24T19:59:33Z
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 Sun, Nov 23, 2025 at 4:55 AM David Rowley <dgrowleyml@gmail.com> wrote:
> One thing that seems to be getting forgotten again is the "/* Stop
> applying cost limits from this point on */" added in 1e55e7d17 is only
> going to be applied when the table *currently* being vaccumed is over
> the failsafe limit. Without Nathan's patch, the worker might end up
> idling along carefully obeying the cost limits on dozens of other
> tables before it gets around to vacuuming the table that's over the
> failsafe limit, then suddenly drop the cost delay code and rush to get
> the table frozen, before Postgres stops accepting transactions. With
> the patch, Nathan has added some aggressive score scaling, which
> should mean any table over the failsafe limit has the highest score
> and gets attended to first.

Right, so can we use that to construct a specific, concrete scenario
where we can see that the patch ends up delivering better behavior
than we have today? I think it would be a really good to have at least
one fully worked-out case where we can say "look, if you run this
series of commands without the patch, X happens, and with the patch, Y
happens, and look! Y is better."

-- 
Robert Haas
EDB: http://www.enterprisedb.com