Horton

Re: another autovacuum scheduling thread

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Treat <rob@xzilla.net>
Cc: David Rowley <dgrowleyml@gmail.com>, Sami Imseih <samimseih@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Jeremy Schneider <schneider@ardentperf.com>, pgsql-hackers@postgresql.org
Date: 2025-11-11T20:16:37Z
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 Tue, Nov 11, 2025 at 02:50:55PM -0500, Robert Treat wrote:
> On Tue, Nov 11, 2025 at 2:49 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
>> On Tue, Nov 11, 2025 at 02:43:19PM -0500, Robert Treat wrote:
>> > FWIW, when I have built these types of systems in the past, and when I
>> > wanted an aggressive recheck-type mechanism, the most common methods
>> > involved tying it to autovacuum_max_workers.
>>
>> Would you mind elaborating on this point?  Do you mean that you'd rebuild
>> the list every a_m_w tables, or something else?
> 
> Yes.

Interesting.  With our defaults, that would mean rebuilding the list every
few tables, which seems quite aggressive.  I'd start worrying about the
pg_class scanning overhead a little...

-- 
nathan