Re: allow changing autovacuum_max_workers without restarting - Mailing list pgsql-hackers

From Tom Lane
Subject Re: allow changing autovacuum_max_workers without restarting
Date
Msg-id 1052019.1745947915@sss.pgh.pa.us
Whole thread Raw
In response to Re: allow changing autovacuum_max_workers without restarting  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: allow changing autovacuum_max_workers without restarting
List pgsql-hackers
I wrote:
> Andres seemed lukewarm about reverting 38da05346 or 6d0154196, so
> I left it be for the moment.  But I still feel the argument is good
> that "these will do little except confuse future hackers".  Barring
> objection, I'll go revert them.

Actually ... on looking again at 6d0154196 ("Lower default value of
autovacuum_worker_slots in initdb as needed"), it doesn't look that
silly.  If we're unable to allocate max_connections = 100, turning
it down while still insisting on 16 AV worker slots doesn't seem
terribly sane.  Maybe we'd choose a formula other than
"(max_connections / 6)" if we were doing it afresh, but not scaling
autovacuum_worker_slots at all doesn't seem like the best answer.

So now I'm inclined to leave that one alone.  I'd still revert
38da05346, which means the comment added by 6d0154196 needs some minor
adjustments.  But I think we can stick with the "(max_connections /
6)" formula --- it will produce 3 with trial_conns = 20, but that's
enough.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Alexander Pyhalov
Date:
Subject: Re: MergeAppend could consider sorting cheapest child path
Next
From: Nathan Bossart
Date:
Subject: Re: Large expressions in indexes can't be stored (non-TOASTable)