public inbox for [email protected]
help / color / mirror / Atom feedFrom: Sami Imseih <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Robert Treat <[email protected]>
Cc: David Rowley <[email protected]>
Cc: Jeremy Schneider <[email protected]>
Cc: [email protected]
Subject: Re: another autovacuum scheduling thread
Date: Thu, 20 Nov 2025 10:34:14 -0600
Message-ID: <CAA5RZ0vJH5k+tWbCG-tLfSCb7=jngwLkQHdwPLo8gP92mg2i_g@mail.gmail.com> (raw)
In-Reply-To: <aR9BATffJN-hmQ1w@nathan>
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>
> On Thu, Nov 20, 2025 at 09:30:42AM -0500, Robert Haas wrote:
> > Point being: I think we need to avoid the mindset that we can't be
> > stupider than we are now. I don't think there's any way we would
> > commit something that is GENERALLY stupider than we are now, but it's
> > not about averages. It's about whether there are specific cases that
> > are common enough to worry about which end up getting regressed. I'm
> > honestly not sure how much of a risk that is, and, again, I'm not
> > trying to kill the patch. It might well be that the patch is already
> > good enough that such scenarios will be extremely rare. However, it's
> > easy to get overconfident when replacing a completely unintelligent
> > system with a smarter one. The risk of something backfiring can
> > sometimes be higher than one anticipates.
>
> That's a fair point. The possibly-entirely-theoretical case that's in my
> head is when your oldest and lowest-OID table is also the biggest and most
> active. That seems like it could be a popular pattern in the field, and it
> probably benefits to some degree from the sequential scan returning it
> earlier. I don't know how much to worry about stuff like this.
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 has been
the only behavior ever since autovacuum was released, there should be a way
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.
--
Sami Imseih
Amazon Web Services (AWS)
view thread (143+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: another autovacuum scheduling thread
In-Reply-To: <CAA5RZ0vJH5k+tWbCG-tLfSCb7=jngwLkQHdwPLo8gP92mg2i_g@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox