Hi,
On Tue, Mar 31, 2026 at 2:46 PM SATYANARAYANA NARLAPURAM
<satyanarlapuram@gmail.com> wrote:
>
> On Mon, Mar 30, 2026 at 1:44 AM Daniil Davydov <3danissimo@gmail.com> wrote:
>>
>> Actually, autovacuum_max_parallel_workers is already limited by
>> max_parallel_workers. It is not clear for me why we allow setting this GUC
>> higher than max_parallel_workers, but if this happens, I think it is a user's
>> misconfiguration.
>
> Isn’t there a wasted effort here if user misconfigures because anyway we cannot launch that many workers? I suggest
makinga check here.
We have a pretty long discussion about this in the above messages. I also
think that the user have too many ways to misconfigure postgres. But we
don't consider such misconfiguration as our fault.
>> Parallel a/v workers inherit cost based parameters (including the
>> vacuum_cost_limit) from the leader worker. Do you mean that this can be too
>> low value for parallel operation? If so, user can manually increase the
>> vacuum_cost_limit reloption for those tables, where parallel a/v sleeps too
>> much (due to cost delay).
>
>
> They don’t inherit but share, isn’t it?
>
Yeah, let me clarify. At the beginning of parallel a/v, the leader a/v worker
creates and initializes a shared structure, where its cost based parameters
are stored. Then, all parallel workers will read them from shmem and update
their parameters accordingly.
--
Best regards,
Daniil Davydov
