| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Robert Treat <rob(at)xzilla(dot)net>, David Rowley <dgrowleyml(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: another autovacuum scheduling thread |
| Date: | 2025-11-20 16:25:37 |
| Message-ID: | aR9BATffJN-hmQ1w@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Maxim Orlov | 2025-11-20 16:30:51 | Re: POC: make mxidoff 64 bits |
| Previous Message | Nathan Bossart | 2025-11-20 16:12:47 | Re: pgsql: Teach DSM registry to ERROR if attaching to an uninitialized ent |