Re: EXPLAIN: showing ReadStream / prefetch stats - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: EXPLAIN: showing ReadStream / prefetch stats
Date
Msg-id CAAKRu_ZdAF-Jv1X8WpEpr=eq5owcx0YSm0VpDh8DPNFQKxC4ug@mail.gmail.com
Whole thread
In response to Re: EXPLAIN: showing ReadStream / prefetch stats  (Tomas Vondra <tomas@vondra.me>)
Responses Re: EXPLAIN: showing ReadStream / prefetch stats
List pgsql-hackers
On Tue, Apr 7, 2026 at 8:36 AM Tomas Vondra <tomas@vondra.me> wrote:
>
> 3) Used (es_instrument & INSTRUMENT_IO) more consistently. A couple
> places in the executor still checked just es_instrument, and so would
> collect stats even if not needed.  Be consistent.

I would argue for only allocating the shared instrumentation if they
will be displayed, but I don't feel that strongly about it.

I took another look at just 0002 just to double-check the read stream
counters. It seems fine.
Perhaps we should free the TableScanInstrumentation in heap_endscan().
It isn't that important of a leak, but the other things palloc'd in
heap_beginscan() are freed.

I also wondered if it is clear without a comment why we don't count a
wait when READ_BUFFERS_SYNCHRONOUSLY sets needed_wait (which we added
to make sure distance ramps up). I think it's fine; I'm just musing.

- Melanie



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: EXPLAIN: showing ReadStream / prefetch stats
Next
From: Antonin Houska
Date:
Subject: Re: Adding REPACK [concurrently]