Re: Parallel vacuum: workers together with leader could overrun cost budget

Hi,

On Thu, Oct 22, 2026 at 5:53 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
> > I think there are a couple of ways to handle this:
>
> > 2/ Cap the delay per worker at 1s (similar to
> > WaitExceedsMaxStandbyDelay()) i.e. Min(Min(msec, cost_delay * 4 *
> > nworkers), 1000). This still looks fine, and it's better than today's
> > 400ms limit.
>
> Wouldn't the 1-second cap still allow the cost budget to be exceeded in some cases, which is exactly what this patch is trying to fix? If so, wouldn't that leave the fix incomplete?

I think the 1s cap with pg_usleep() is fine here. For any worker or
the leader to reach the cap, its cost balance has to be far above its
share of the cost limit (VacuumCostBalanceLocal/vacuum_cost_limit >=
4x), which only happens when many delay points are skipped. E.g., with
cost delay 100ms, cost limit 200, and 16 processes, each process gets
12.5, so VacuumCostBalanceLocal has to reach 800 to hit 4x, which
means skipping about 40 delay points while dirtying pages, or about
400 while reading pages. That looks rare in practice, so I prefer to
keep the 1s cap with pg_usleep().

That said, the WaitLatch() approach might be worth discussing for
HEAD, though I don't feel strongly about it. One other idea with the
1s cap is to carry the leftover balance over to the next delay point,
but I don't think it's worth the complexity.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com