Re: parallel autovacuum: Propagate track_cost_delay_timing to parallel workers

Hi,

On Mon, Sep 28, 2026 at 5:13 PM Sami Imseih <samimseih(dot)pg(at)gmail(dot)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