Hi, On Tue, Mar 31, 2026 at 2:46 PM SATYANARAYANA NARLAPURAM <[email protected]> wrote: > > On Mon, Mar 30, 2026 at 1:44 AM Daniil Davydov <[email protected]> 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 making a 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
