parallel autovacuum: Propagate track_cost_delay_timing to parallel workers

Hi,

On Fri, Sep 25, 2026 at 8:42 AM Sami Imseih <samimseih.pg@gmail.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

Hi Bharath,

Thanks for the feedback!

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?

track_cost_delay_timing gates delay timing reporting elsewhere, so we should not
deviate from that. If the GUC is off by then, we should not accumulate
any timing
anyhow, even if parallel_vacuum_worker_delay_ns > 0

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.

Right. I did not think it should matter.

--
Sami Imseih
Amazon Web Services

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

+1, the patch looks good to me.

Hi,

On Fri, Sep 25, 2026 at 8:41 AM Sami Imseih <samimseih.pg@gmail.com> wrote:

Hi,

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.

CC Sawada-san and Zsolt since there is a related discussion in [1], though
that one is about throttling.

Thank you for the report and the patch! Good catch. The patch looks
good to me overall and works as expected. I have one minor comment
though:

int cost_page_miss;
+ bool track_delay_timing;
} PVSharedCostParams;

I think using track_cost_delay_timing seems better in terms of greppability.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

On Mon, Sep 28, 2026 at 2:34 PM Sami Imseih <samimseih.pg@gmail.com> wrote:

Hi Bharath,

Thanks for the feedback!

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?

track_cost_delay_timing gates delay timing reporting elsewhere, so we should not
deviate from that. If the GUC is off by then, we should not accumulate
any timing
anyhow, even if parallel_vacuum_worker_delay_ns > 0

IIUC the remaining parallel_vacuum_worker_delay_ns was accumulated
when the track_cost_delay_timing was enabled. Shouldn't we report it
as well?

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

track_cost_delay_timing gates delay timing reporting elsewhere, so we should not
deviate from that. If the GUC is off by then, we should not accumulate
any timing
anyhow, even if parallel_vacuum_worker_delay_ns > 0

IIUC the remaining parallel_vacuum_worker_delay_ns was accumulated
when the track_cost_delay_timing was enabled. Shouldn't we report it
as well?

We could swap
```
/* Report any remaining cost-based vacuum delay time */
if (track_cost_delay_timing)
```

with

```
/* Report any remaining cost-based vacuum delay time */
if (parallel_vacuum_worker_delay_ns)
```

but I did not think that made sense. When we get to the point of reporting
the remaining time, and the track_cost_delay_timing is disabled, then
I don't think we should report anything.

--
Sami

Hi,

On Mon, Sep 28, 2026 at 5:13 PM Sami Imseih <samimseih.pg@gmail.com> wrote:

track_cost_delay_timing gates delay timing reporting elsewhere, so we should not
deviate from that. If the GUC is off by then, we should not accumulate
any timing
anyhow, even if parallel_vacuum_worker_delay_ns > 0

IIUC the remaining parallel_vacuum_worker_delay_ns was accumulated
when the track_cost_delay_timing was enabled. Shouldn't we report it
as well?

We could swap
```
/* Report any remaining cost-based vacuum delay time */
if (track_cost_delay_timing)
```

with

```
/* Report any remaining cost-based vacuum delay time */
if (parallel_vacuum_worker_delay_ns)
```

but I did not think that made sense. When we get to the point of reporting
the remaining time, and the track_cost_delay_timing is disabled, then
I don't think we should report anything.

I think it depends on how much accumulated time it will be at max from
the last report till the end of parallel_vacuum_main(). If it is in
minutes or even tens of seconds, then losing that last part would make
the reported delay time incomplete.

That said, I checked track_wal_io_timing and it reports the
accumulated timing even after the GUC is turned off, see
pgstat_count_io_op_time(). IIUC, what matters there is whether timing
was on when the start time was captured, not what it is at reporting
time. Looking at that, I would prefer reporting the remaining
accumulated time here too to make it complete.

Also, +1 to rename track_delay_timing to GUC name.

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

Hi,

That said, I checked track_wal_io_timing and it reports the
accumulated timing even after the GUC is turned off, see
pgstat_count_io_op_time(). IIUC, what matters there is whether timing
was on when the start time was captured, not what it is at reporting
time. Looking at that, I would prefer reporting the remaining
accumulated time here too to make it complete.

Fair enough.

I guess this also fits better with the existing comment.

```
/* Report any remaining cost-based vacuum delay time */
```

Also, +1 to rename track_delay_timing to GUC name.

Done.

v2 attached.

--
Sami

Hi,

On Mon, Sep 28, 2026 at 9:12 PM Sami Imseih <samimseih.pg@gmail.com> wrote:

That said, I checked track_wal_io_timing and it reports the
accumulated timing even after the GUC is turned off, see
pgstat_count_io_op_time(). IIUC, what matters there is whether timing
was on when the start time was captured, not what it is at reporting
time. Looking at that, I would prefer reporting the remaining
accumulated time here too to make it complete.

Fair enough.

I guess this also fits better with the existing comment.

```
/* Report any remaining cost-based vacuum delay time */
```

Also, +1 to rename track_delay_timing to GUC name.

Done.

v2 attached.

Thanks. v2 looks good to me. pgindent and tests are happy, and the
same patch applies on PG19 as well.

One nit, please feel free to ignore it. VacuumUpdateCosts() prints
yes/no for booleans, so on/off here could match that for consistency.
AFAICS, there is no hard rule, and I am fine with it as is.

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

One nit, please feel free to ignore it. VacuumUpdateCosts() prints
yes/no for booleans, so on/off here could match that for consistency.
AFAICS, there is no hard rule, and I am fine with it as is.

Better to be consistent here. Attached is v3-, which also updates the test
output expected.

--
Sami Imseih
Amazon Web Services (AWS)

Hi,

On Tue, Sep 29, 2026 at 6:48 AM Sami Imseih <samimseih.pg@gmail.com> wrote:

One nit, please feel free to ignore it. VacuumUpdateCosts() prints
yes/no for booleans, so on/off here could match that for consistency.
AFAICS, there is no hard rule, and I am fine with it as is.

Better to be consistent here. Attached is v3-, which also updates the test
output expected.

Thanks. v3 path looks good to me.

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

On Tue, Sep 29, 2026 at 08:45:17AM -0700, Bharath Rupireddy wrote:

Thanks. v3 path looks good to me.

Yeah, reading through v3, that's not cool. @Sawada-san, perhaps you
should look at that before v19 releases..
--
Michael

On Sun, Oct 4, 2026 at 11:25 PM Michael Paquier <michael@paquier.xyz> wrote:

On Tue, Sep 29, 2026 at 08:45:17AM -0700, Bharath Rupireddy wrote:

Thanks. v3 path looks good to me.

Yeah, reading through v3, that's not cool. @Sawada-san, perhaps you
should look at that before v19 releases..

Yes, the patch looks good to me too. I'm going to push it, barring objections.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

On Mon, Oct 5, 2026 at 9:10 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Sun, Oct 4, 2026 at 11:25 PM Michael Paquier <michael@paquier.xyz> wrote:

On Tue, Sep 29, 2026 at 08:45:17AM -0700, Bharath Rupireddy wrote:

Thanks. v3 path looks good to me.

Yeah, reading through v3, that's not cool. @Sawada-san, perhaps you
should look at that before v19 releases..

Yes, the patch looks good to me too. I'm going to push it, barring objections.

Pushed.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com