Hi On Mon, Mar 30, 2026 at 1:44 AM Daniil Davydov <[email protected]> wrote:
> Hi, > > On Mon, Mar 30, 2026 at 7:17 AM SATYANARAYANA NARLAPURAM > <[email protected]> wrote: > > > > Thank you for working on this, very useful feature. Sharing a few > thoughts: > > > > 1. Shouldn't we also cap by max_parallel_workers to avoid wasting DSM > resources in parallel_vacuum_compute_workers? > > 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. > > > > 2. Is it intentional that other autovacuum workers not yield cost limits > to the parallel auto vacuum workers? Cost limits are distributed first > equally to the autovacuum workers. > > and then they share that. Therefore, parallel workers will be heavily > throttled. IIUC, this problem doesn't exist with manual vacuum. > > If we don't fix this, at least we should document this. > > 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? > > BTW, describing the cost limit propagation to the parallel a/v workers is > worth mentioning in the documentation. I'll add it in the next patch > version. Yes, that helps > > > > 3. Additionally, is there a point where, based on the cost limits, > launching additional workers becomes counterproductive compared to running > fewer workers and preventing it? > > I don't think that we can possibly find a universal limit that will be > appropriate for all possible configurations. By now we are using a pretty > simple formula for parallel degree calculation. Since user have several > ways > to affect this formula, I guess that there will be no problems with it > (except > my concerns about opt-out style). Thanks, Satya > >
