Re: parallel autovacuum: Propagate track_cost_delay_timing to parallel workers

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Subject: Re: parallel autovacuum: Propagate track_cost_delay_timing to parallel workers
Date: 2026-09-26 04:24:37
Message-ID: CALj2ACW1gjnDPX3MZidthJdb2X+VBF_CwRhCBqtM7XFn9RkOsg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Fri, Sep 25, 2026 at 8:42 AM Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> wrote:
>
> Here is a small patch to propagate track_cost_delay_timing to parallel
> autovacuum workers. 1ff3180ca01 propagates the cost-based delay
> parameters via PVSharedCostParams but left this one out, so a worker keeps
> the value it inherited at parallel start, and workers will not report
> sleep time if the GUC is turned on mid-flight.
>
> This only impacts delay reporting, but should be backpatched to 19 which
> introduced parallel autovacuum.

Nice catch. Yes, when enabled, the parallel workers don't report their
cost delay to the autovacuum worker (leader), so only the leader's
cost delay is reported.

Enabling it can have some overhead on certain platforms while getting
the time, since the vacuum delay points are spread across the code.
But when enabled, the workers not reporting their delay loses the
benefit this GUC was added for, which is to reliably measure the
impact of cost delay and cost limit changes on the vacuum duration.
The user may have changed the cost limit and delay to slow things down
or speed them up, and either way it is not good for the reported
timing to miss the delay from the workers.

So this is definitely a bug IMHO and an oversight in 1ff3180ca01. +1
to back-patch it to PG19.

The v1 patch looks good to me with a few nits:

1/ At the end of parallel_vacuum_main(), do we need to gate the
reporting of any remaining delay time on the accumulated delay time
variable rather than on the GUC? Now that the GUC can change in a
worker, if it is turned off after some delay time has accumulated
since the last report, that remainder is never reported. It is a
little less than a second at most, so I guess that is fine either way.

2/ Turning it on in the TAP test is probably not that costly on any of
the CI or BF animals, since our tests don't vacuum anything large, so
it shouldn't matter.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Japin Li 2026-09-26 03:25:16 Re: ZSTD TOAST compression, and an extensible compression method encoding