MIME-Version: 1.0
References: 
 <CAApHDvq_j+GVqX_ZAmvn236Mgg5OYQ6_s9kVsyoo1tJa2RJ=2w@mail.gmail.com>
 <CAA5RZ0udjEYJupob5tv3286e28bMpajgsy+4nAbxg73YyigZFw@mail.gmail.com>
 <CAApHDvq9ecYSetXUhjMc7E_Jcc7gxxRkA0LosX9PP1-jM_Ak8A@mail.gmail.com>
 <aRNmEPQ18qZlLowV@nathan>
 <CAApHDvrtvMF3_W69hOUr2SnbizjC1jc68_Ca0nPYr=+VUkUkAw@mail.gmail.com>
 <aROY-MUVO_mYTl2f@nathan>
 <CAApHDvpo3YxiaP123vghHL-aLkY2vc-e1scpDSpaTFWz1qVaQA@mail.gmail.com>
 <CABV9wwOcD4RM5Hm0d+=KBK8LyHLtEtF3YZ4ak8V3VvOYV9Z4Tw@mail.gmail.com>
 <aRTpqMleDpoQm9OO@nathan>
 <CA+TgmoY27S+nbgdCrVrc8S4p38NwTAC8_Uyq5ZaX6zxYToebXA@mail.gmail.com>
 <aR9BATffJN-hmQ1w@nathan>
 <CAA5RZ0vJH5k+tWbCG-tLfSCb7=jngwLkQHdwPLo8gP92mg2i_g@mail.gmail.com>
In-Reply-To: 
 <CAA5RZ0vJH5k+tWbCG-tLfSCb7=jngwLkQHdwPLo8gP92mg2i_g@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Thu, 20 Nov 2025 13:35:52 -0500
Message-ID: 
 <CA+TgmobEGG4pUzLMY-02N_FEY8uW4520X3rTB+BdVNUkLzDLMQ@mail.gmail.com>
Subject: Re: another autovacuum scheduling thread
To: Sami Imseih <samimseih@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Robert Treat <rob@xzilla.net>,
	David Rowley <dgrowleyml@gmail.com>,
 Jeremy Schneider <schneider@ardentperf.com>,
	pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BTgmobEGG4pUzLMY-02N_FEY8uW4520X3rTB%2BBdVNUkLzDLMQ%40mail.gmail.com>
Precedence: bulk

On Thu, Nov 20, 2025 at 11:34=E2=80=AFAM Sami Imseih <samimseih@gmail.com> =
wrote:
> I think it would be difficult to introduce this new prioritization
> system without a
> GUC to control the prioritization behavior. Since ordering by pg_class ha=
s been
> the only behavior ever since autovacuum was released, there should be a w=
ay
> for users to revert back to this. The default could be the new
> prioritization strategy.
>
> Introducing new GUCs is something to be avoided if possible, but I think =
this
> case is a clear one to me.

As I sort of alluded to in my previous message, I'd rather see us
introduce something that lets you get the behavior you want than
something that just lets you get back to the old behavior.
Technically, the latter is good enough to avoid any claim that we've
regressed things: you can always just the new thing off, and so by
definition there are no unavoidable regressions. But that only caters
to the scenario where the current behavior is good by accident
(because it can never be good for any other reason).

Don't take this too literally, but just mooting ideas wildly, suppose
the scoring has a wraparound component, a bloat component, and a
reloption-driven component, and the former two have a weighting factor
that can be adjusted via GUCs. If you want to shut off the new
behavior, you can setting the weighting factors to 0. If you want to
keep the new behavior but adjust the trade-off between the wraparound
and bloat components, you can adjust the relative weighting factors
between the two. If you want to take more manual control, you can use
the reloption, a choice that you can layer on top of the default
strategy or any of the alternate strategies just proposed. Of course,
making this all too complicated is a recipe for failure, but I suspect
that making it at least somewhat configurable is a good idea.

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