>>> That's true, but using a hard-coded limit means we no longer need to add a
>>> new GUC. Always allocating, say, 256 slots might require a few additional
>>> kilobytes of shared memory, most of which will go unused, but that seems
>>> unlikely to be a problem for the systems that will run Postgres v18.
>>
>> I agree with this.
> Here's what this might look like. I chose an upper limit of 1024, which
> seems like it "ought to be enough for anybody," at least for now.
I thought 256 was a good enough limit. In practice, I doubt anyone will
benefit from more than a few dozen autovacuum workers.
I think 1024 is way too high to even allow.
Besides that the overall patch looks good to me, but I have
some comments on the documentation.
I don't think combining 1024 + 5 = 1029 is a good idea in docs.
Breaking down the allotment and using the name of the constant
is much more clear.
I suggest
" max_connections + max_wal_senders + max_worker_processes + AUTOVAC_MAX_WORKER_SLOTS + 5"
and in other places in the docs, we should mention the actual
value of AUTOVAC_MAX_WORKER_SLOTS. Maybe in the
below section?
Instead of:
- (<xref linkend="guc-autovacuum-max-workers"/>) and allowed background
+ (1024) and allowed background
do something like:
- (<xref linkend="guc-autovacuum-max-workers"/>) and allowed background
+ AUTOVAC_MAX_WORKER_SLOTS (1024) and allowed background
Also, replace the 1024 here with AUTOVAC_MAX_WORKER_SLOTS.
+ <varname>max_wal_senders</varname>,
+ plus <varname>max_worker_processes</varname>, plus 1024 for autovacuum
+ worker processes, plus one extra for each 16
Also, Not sure if I am mistaken here, but the "+ 5" in the existing docs
seems wrong.
If it refers to NUM_AUXILIARY_PROCS defined in
include/storage/proc.h, it should a "6"
#define NUM_AUXILIARY_PROCS 6
This is not a consequence of this patch, and can be dealt with
In a separate thread if my understanding is correct.
Regards,
Sami
