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

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Parallel vacuum: workers together with leader could overrun cost budget
Date: 2026-10-21 17:37:52
Message-ID: CALj2ACXsDZR5kpsbOTHHVNNfJuN+9_x=8XzKh2Yc-0yTCwtu7g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Tue, Oct 20, 2026 at 2:01 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> > Please find the attached v2 patch with the above changes and some doc
> > adjustments.
>
> Thank you for updating the patch! The patch looks good to me. It's
> nice to update the documentation part about (vacuum_cost_delay * 4 *
> nworkers) limit.

Thanks for reviewing it.

> I think this patch should be backpatched to all supported branches
> because the VACUUM command with the PARALLEL option should honor the
> cost-based delay although it's disabled by default. What do you think?

Yes, back-patching makes sense to me. IMHO it's a bug in parallel
vacuum (40d964ec99). AFAICS it hasn't been reported anywhere. I have
seen the VACUUM command run with a parallel degree when approaching
XID wraparound. At that point one wants the vacuum to finish faster,
so overrunning the cost is fine. I'm not sure, but it could also have
gone unnoticed for those running VACUUM command cron jobs. That said,
one can always tune the cost limit to speed things up or down.

In any case, I'm fine with fixing it in the back-branches. I can send
the patches for the back-branches.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-10-21 18:00:40 Re: [DEPARSE] EXPLAIN prints another ModifyTable's RETURNING aliases in a SubPlan
Previous Message Tom Lane 2026-10-21 17:09:38 Re: [DEPARSE] EXPLAIN prints another ModifyTable's RETURNING aliases in a SubPlan