Re: Parallel vacuum: I/O timings in the log leave out the parallel workers

On Wed, Oct 7, 2026 at 1:41 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Wed, Sep 30, 2026 at 9:18 PM Bharath Rupireddy
> <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> >
> > Hi,
> >
> > On Mon, Sep 28, 2026 at 11:09 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > >
> > > Yes, I think we should treat it the same way as 5cd72cc0c5.
> > >
> > > We need to note that in 16 BufferUsage doesn't have
> > > local_blk_{read|write}_time, and pgstat_count_io_op_time() adds the
> > > I/O time of temp relations only to pgStatBlockReadTime and
> > > pgStatBlockWRiteTime, not to BufferUsage.blk_{read|write}_time. So
> > > taking the timings from BufferUsage would drop the time spent on temp
> > > relations from the log. In 15, blk_{read|write}_time and
> > > pgStatBlock{Read|Write}TIme cover the same I/O, so the fix would be
> > > straightforward, but I don't think it's worth leaving 16 unfixed in
> > > between, or adding 16-specific code for a reporting issue. So I'm
> > > inclined to backpatch it to 17. Thoughts?
> >
> > Agreed. +1 to keeping the version diff minimal as far back as possible
> > with less invasive changes, so back-patching it to PG17 makes sense to
> > me. Please find the attached v2 patch.
>
> Thank you for updating the patches! They look good to me.
>
> > I did not add the ANALYZE change suggested upthread, because ANALYZE
> > has no parallel workers and so does not have the inconsistency
> > reported in this thread. It might still be worth doing for consistency
> > with VACUUM.
>
> +1
>
> I'm going to push them tomorrow, barring objections.
>

Pushed.

Regards,

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