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