Re: EXPLAIN: showing ReadStream / prefetch stats
Melanie Plageman <melanieplageman@gmail.com>
From: Melanie Plageman <melanieplageman@gmail.com>
To: Tomas Vondra <tomas@vondra.me>
Cc: Andres Freund <andres@anarazel.de>, Lukas Fittl <lukas@fittl.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-05T22:18:28Z
Lists: pgsql-hackers
Attachments
- v8-alt-0001-switch-explain-to-unaligned-for-json-xml-yaml.patch (text/x-patch) patch v8-0001
- v8-alt-0002-separate-shared-instrumentation-initializatio.patch (text/x-patch) patch v8-0002
- v8-alt-0003-fix-bhs-non-parallel-aware-explain-analyze.patch (text/x-patch) patch v8-0003
- v8-alt-0004-Add-EXPLAIN-IO-infrastructure-and-BitmapHeapS.patch (text/x-patch) patch v8-0004
- v8-alt-0005-Add-EXPLAIN-IO-instrumentation-for-SeqScan.patch (text/x-patch) patch v8-0005
- v8-alt-0006-Add-EXPLAIN-IO-instrumentation-for-TidRangeSc.patch (text/x-patch) patch v8-0006
- v8-alt-0007-other-test-changes.patch (text/x-patch) patch v8-0007
On Fri, Apr 3, 2026 at 3:01 PM Tomas Vondra <tomas@vondra.me> wrote: > > 1) stats for non-parallel-aware scans > > It correctly shows stats for scans that are not parallel-aware. <--snip--> > For SeqScan/TidRangeScan I've merged the changes into 0004 and 0005. > > I have to admit I'm not a huge fan of the changes required to fix this. > The logic with all these instument/parallel_aware conditions seems much > less readable to me, but I don't know how else to do this. The approach > is copied from nodeIndexscan.c, which already did that in 0fbceae841cb. While this is the opposite direction of what I suggested to fix BHS in [1], what if we allocated the instrumentation and parallel-aware state separately and accessed them with their own keys? It's a little janky because what key could we use besides the plan_node_id, but if we add a key-sized offset to the plan node id, we can functionally have two separate keys. We could do this for all nodes that have both shared instrumentation and parallel-aware shared state. It introduces some boilerplate functions, but I do find it easier to understand. I've attached patches that implement this to make the idea more clear. 0002 does the two allocations for the existing index[-only] scan nodes. 0003 uses this method to fix BHS. 0004 is your patch to add prefetch stuff to explain and show it for BHS. And 0005 and 0006 are using the two allocation approach for seqscan and tidrange scan. There were some test changes you had that didn't seem required to make tests pass in the commits that I stuffed into 0007. I used an LLM to do some of the boilerplate and rebasing, so there might be some weirdness in there. If we don't do the above, then I think your current approach is the only other realistic option. We can't do what I suggested for BHS in [1] and always allocate the parallel-aware state because that state is much larger for sequential scans and TID range scans. - Melanie [1] https://www.postgresql.org/message-id/CAAKRu_a_c8HAtJ8Ynz-dU%3DJb2PzheW0zWME6A1BB9jQ62DMZBg%40mail.gmail.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
bufmgr: Return whether WaitReadBuffers() needed to wait
- 513374a47a71 19 (unreleased) landed