Re: EXPLAIN: showing ReadStream / prefetch stats

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: Lukas Fittl <lukas(at)fittl(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: EXPLAIN: showing ReadStream / prefetch stats
Date: 2026-04-07 15:27:00
Message-ID: CAAKRu_ZdAF-Jv1X8WpEpr=eq5owcx0YSm0VpDh8DPNFQKxC4ug@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 7, 2026 at 8:36 AM Tomas Vondra <tomas(at)vondra(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Antonin Houska 2026-04-07 15:38:24 Re: Adding REPACK [concurrently]
Previous Message Andres Freund 2026-04-07 15:09:40 Re: EXPLAIN: showing ReadStream / prefetch stats