Horton

Re: another autovacuum scheduling thread

Jeremy Schneider <schneider@ardentperf.com>

View thread
From: Jeremy Schneider <schneider@ardentperf.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>, Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers@postgresql.org
Date: 2025-10-09T01:47:40Z
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, 8 Oct 2025 18:25:20 -0700
Jeremy Schneider <schneider@ardentperf.com> wrote:

> On Thu, 9 Oct 2025 14:03:34 +1300
> David Rowley <dgrowleyml@gmail.com> wrote:
> 
> > I thought if we're to have a priority queue that it would be hard to
> > argue against sorting by how far over the given auto-vacuum
> > threshold that the table is.  If you assume that a table that just
> > meets the dead rows required to trigger autovacuum based on the
> > autovacuum_vacuum_scale_factor setting gets a priority of 1.0, but
> > another table that has n_mod_since_analyze twice over the
> > autovacuum_analyze_scale_factor gets priority 2.0.  Effectively,
> > prioritise by the percentage over the given threshold the table is.
> > That way users could still tune things when they weren't happy with
> > the priority given to a table by adjusting the corresponding
> > reloption.
> 
> If users are tuning this thing then I feel like we've already lost the
> battle :)

I replied too quickly. Re-reading your email, I think your proposing a
different algorithm, taking tuple counts into account. No tunables. Is
there a fully fleshed out version of the proposed alternative algorithm
somewhere? (one of the older threads?) I guess this is why its so hard
to get anything committed in this area...

-J