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

Hi,

On Tue, Oct 13, 2026 at 8:46 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> Hi,
>
> I noticed that the parallel workers can go over the vacuum cost
> budget, with both parallel vacuum and parallel autovacuum. For
> example, with the default cost delay of 2ms and cost limit of 200,
> each of the 4 parallel workers and the autovacuum worker (the leader)
> sleeps 2ms for every 200 cost units it incurs on its own, so each of
> the 5 processes runs at the full budget. If the 200 were the budget
> for the vacuum as a whole, each process would have to sleep 5 times
> longer, that is 2ms per 40 cost units.
>
> I think this is a problem, since the cost budget the user was promised
> gets crossed. Please find the attached patch fixing this.

Thank you for the report and the patch. I agree with your analysis.
Currently each process sleeps in proportion to the cost it incurred by
itself, so the leader and its workers together consume N times the
budget. I think the cost limit should work like a rate limit of a
download manager for example: using 5 connections makes the download
after, but if we set the limit to 1MB/s, we expect 1MB/s in total ,
not 1MB/s * 5 = 5MB/s.

> Although this exists for parallel vacuum too, back-patching it to
> PG19, where parallel autovacuum was introduced, is fine, since
> parallel autovacuum runs with the default cost delay and cost limit.

Agree to backpatch it to v19. Autovaucum distributes the cost limit
among the running autovacuum workers so that the sum doesn't exceed
autovacuum_vacuum_cost_limit, but parallel vacuum workers are not
counted there.

I've reviewed the patch and have one comment:

+ /*
+ * Compute sleep time based on the local cost balance and the number
+ * of active workers.
+ */
+ msec = vacuum_cost_delay * VacuumCostBalanceLocal * nworkers /
+ vacuum_cost_limit;

msec can be up to nworkers * vacuum_cost_delay, but
vacuum_delay_point() caps the sleep time at 4 * vacuum_cost_delay.
Therefore, when more than 4 parallel workers are active, the sleep
time is truncated and we still overrun the budget. IIUC the cap was
introduced to avoid uselessly long delays when the cost accumulates
far beyond the limit. I think a simple fix is to sleep up to 4 *
nworkers * vacuum_cost_delay at once. I think that's acceptable since
the sleep time is still proportional to the cost the process actually
incurred.

Regards,

--
Masahiko Sawada

Amazon Web Services: https://aws.amazon.com