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>
 <CA+TgmobEGG4pUzLMY-02N_FEY8uW4520X3rTB+BdVNUkLzDLMQ@mail.gmail.com>
In-Reply-To: 
 <CA+TgmobEGG4pUzLMY-02N_FEY8uW4520X3rTB+BdVNUkLzDLMQ@mail.gmail.com>
From: Sami Imseih <samimseih@gmail.com>
Date: Thu, 20 Nov 2025 14:21:40 -0600
Message-ID: 
 <CAA5RZ0sfdqGUPi2ORGLywOXmmRSGhUDyMz7YKAH30zp7KWKy0A@mail.gmail.com>
Subject: Re: another autovacuum scheduling thread
To: Robert Haas <robertmhaas@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"
Archived-At: 
 <https://www.postgresql.org/message-id/CAA5RZ0sfdqGUPi2ORGLywOXmmRSGhUDyMz7YKAH30zp7KWKy0A%40mail.gmail.com>
Precedence: bulk

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

yes, that is the intention with the GUC. I am worried about
cases in which a user has no way to go back to the old
behavior if the new prioritization strategy causes pain, for
some reason.

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

Well, maybe it was never really good, but it was the only behavior,
and the user tuned and tested their autovacuum settings with this
behavior; whether they actually kew it's based on pg_class ordering
or not ( I know users I worked with that do not realize this ).

I think if we are to think how we can improve prioritization, the
thing in mind is what can we do so users are no longer required
to schedule manual vacuums for specific tables ( which is essentially
how users are currently prioritizing tables ). If we go to rigid strategy
that is being proposed now, will it reduce or eliminate the need for
manually scheduling? I am not so sure.

> 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.

Something like this could. be better since it can both give control over
prioritization and allows to revert to the current behavior.

--
Sami Imseih
Amazon Web Services (AWS)