Hi, On Mon, Sep 28, 2026 at 5:13 PM Sami Imseih <[email protected]> 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
