From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: allow changing autovacuum_max_workers without restarting |
Date: | 2024-06-21 20:44:07 |
Message-ID: | ZnXmF2FVugUVjSxN@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 18, 2024 at 07:43:36PM -0500, Nathan Bossart wrote:
> On Tue, Jun 18, 2024 at 02:33:31PM -0700, Andres Freund wrote:
>> Another one:
>>
>> Have a general cap of 64, but additionally limit it to something like
>> max(1, min(WORKER_CAP, max_connections / 4))
>>
>> so that cases like tap tests don't end up allocating vastly more worker slots
>> than actual connection slots.
>
> That's a clever idea. My only concern would be that we are tethering two
> parameters that aren't super closely related, but I'm unsure whether it
> would cause any problems in practice.
Here is an attempt at doing this. I've added 0001 [0] and 0002 [1] as
prerequisite patches, which helps simplify 0003 a bit. It probably doesn't
work correctly for EXEC_BACKEND builds yet.
I'm still not sure about this approach. At the moment, I'm leaning towards
something more like v2 [2] where the upper limit is a PGC_POSTMASTER GUC
(that we would set very low for TAP tests).
[0] https://commitfest.postgresql.org/48/4998/
[1] https://commitfest.postgresql.org/48/5059/
[2] https://postgr.es/m/20240419154322.GA3988554%40nathanxps13
--
nathan
Attachment | Content-Type | Size |
---|---|---|
v5-0001-add-num_os_semaphores-GUC.patch | text/plain | 8.0 KB |
v5-0002-remove-check-hooks-for-GUCs-that-contribute-to-Ma.patch | text/plain | 4.9 KB |
v5-0003-allow-changing-autovacuum_max_workers-without-res.patch | text/plain | 10.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-06-21 20:51:15 | Re: What is a typical precision of gettimeofday()? |
Previous Message | Robert Haas | 2024-06-21 20:35:44 | Re: POC, WIP: OR-clause support for indexes |