Re: parallel autovacuum: Propagate track_cost_delay_timing to parallel workers - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: parallel autovacuum: Propagate track_cost_delay_timing to parallel workers
Date
Msg-id CALj2ACX3H_5ZdA9jbn7yKdpNPXOxFnD-J-EQ-=HoDEoZFaJ0Mw@mail.gmail.com
Whole thread
In response to Re: parallel autovacuum: Propagate track_cost_delay_timing to parallel workers  (Sami Imseih <samimseih.pg@gmail.com>)
Responses Re: parallel autovacuum: Propagate track_cost_delay_timing to parallel workers
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Credits For v19
Next
From: Sami Imseih
Date:
Subject: Re: parallel autovacuum: Propagate track_cost_delay_timing to parallel workers