Hi, On Thu, Oct 22, 2026 at 5:53 PM Chao Li <[email protected]> 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
