| 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
| 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 |