Date: Wed, 8 Oct 2025 18:25:20 -0700
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
Subject: Re: another autovacuum scheduling thread
Message-ID: <20251008182520.6e05a8b8@ardentperf.com>
In-Reply-To: 
 <CAApHDvpMEs3rewULyJZ=huT8ZM1C1PboV-G7K7jfGtJSgdx-fA@mail.gmail.com>
References: <aOaAuXREwnPZVISO@nathan>
	<CAA5RZ0ucgx6VgVCUYryZY33StMtHSpoND_7wEFjGCVCSjouUsA@mail.gmail.com>
	<20251008164057.6bceb9ed@ardentperf.com>
	<CAApHDvo3maZsrZVq=Bur=Z6Gtse4asSEgHU0HzBhhcTfM-AfeA@mail.gmail.com>
	<20251008172727.3befd129@ardentperf.com>
	<CAApHDvpMEs3rewULyJZ=huT8ZM1C1PboV-G7K7jfGtJSgdx-fA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20251008182520.6e05a8b8%40ardentperf.com>
Precedence: bulk

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 :)

On a healthy system, autovac runs continually and hits tables at
regular intervals based on their steady state change rates. We have
existing knobs (for better or worse) that people can use to tell PG to
hit certain tables more frequently, to get rid of sleeps/delays, etc.

With our fleet of PG databases here, my current approach is geared
toward setting log_autovacuum_min_duration to some conservative value
fleet-wide, then monitoring based on the logs for any cases where it
runs longer than a defined threshold. I'm able to catch problems sooner
this way, versus monitoring on xid age alone.

Whenever there are problems with autovacuum, the actual issue is never
going to be resolved by what order autovacuum processes tables. I don't
think we should encourage any tunables here... to me it seems like
putting focus entirely in the wrong place.

-Jeremy