Re: Parallel vacuum: I/O timings in the log leave out the parallel workers - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Parallel vacuum: I/O timings in the log leave out the parallel workers
Date
Msg-id CALj2ACVuHb+tmARCG1NDP5C70Scmsr2_XYWj1poBd6rDwBqWLQ@mail.gmail.com
Whole thread
In response to Re: Parallel vacuum: I/O timings in the log leave out the parallel workers  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
Hi,

On Mon, Sep 28, 2026 at 11:09 PM Masahiko Sawada <sawada.mshk@gmail.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.

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.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] Clear FatalError earlier during crash restart
Next
From: Michael Paquier
Date:
Subject: Re: Report index currently being vacuumed in pg_stat_progress_vacuum