Re: another autovacuum scheduling thread
| От | Nathan Bossart |
|---|---|
| Тема | Re: another autovacuum scheduling thread |
| Дата | |
| Msg-id | aR9BATffJN-hmQ1w@nathan обсуждение исходный текст |
| Ответ на | Re: another autovacuum scheduling thread (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: another autovacuum scheduling thread
Re: another autovacuum scheduling thread |
| Список | pgsql-hackers |
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. -- nathan
В списке pgsql-hackers по дате отправления: