Re: parallel autovacuum: Propagate track_cost_delay_timing to parallel workers

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

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-09-29 00:35:06 Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation
Previous Message jian he 2026-09-29 00:00:00 Re: create table like including storage parameter