| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: another autovacuum scheduling thread |
| Date: | 2025-11-22 20:03:54 |
| Message-ID: | aSIXKuNtMU33r57X@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Nov 22, 2025 at 06:28:13AM -0500, Robert Haas wrote:
> What would be an issue is if we
> regressed some kind of common pattern. I admit that's a bit
> speculative and I'm probably being a little paranoid here: doing smart
> things is typically better than doing dumb things, and what we're
> doing right now is dumb.
>
> On the other hand, once we ship something, we can't pull it back. If
> it causes a problem, someone will call me at 2am and need their system
> fixed right now. If my answer is "well, there are no configuration
> knobs we can change and no way to get back to the old behavior and I'm
> sorry you're having that problem but the only answer is for you to run
> all your VACUUMs manually until two years from now when maybe the
> algorithm will have been improved," it's not going to be a very good
> night. After 15 years at EDB, I've learned that the problem isn't
> being wrong per se; it's having no way to get out from under being
> wrong.
Yeah. I'm tempted to code up the "weighting factor" GUCs for the next
revision. As you've noted, those would be useful for tuning and for
reverting back to pre-v19 behavior. Sure, we might end up with a handful
of retail GUCs that most users don't need, but that's not so terrible.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniil Davydov | 2025-11-22 20:13:03 | Re: POC: Parallel processing of indexes in autovacuum |
| Previous Message | Bernice Southey | 2025-11-22 19:44:19 | Re: Add notification on BEGIN ATOMIC SQL functions using temp relations |