Re: RFC: Allow EXPLAIN to Output Page Fault Information
Atsushi Torikoshi <torikoshia.tech@gmail.com>
From: Atsushi Torikoshi <torikoshia.tech@gmail.com>
To: vellaipandiyan sm <vellaipandiyan.sm@gmail.com>
Cc: torikoshia <torikoshia@oss.nttdata.com>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2026-05-22T16:07:12Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Avoid leaking system path from pg_available_extensions
- db5ed03217b9 19 (unreleased) cited
-
Enable BUFFERS with EXPLAIN ANALYZE by default
- c2a4078ebad7 18.0 cited
Attachments
- v11-0001-Add-storage-I-O-tracking-to-BUFFERS-option.patch (application/octet-stream) patch v11-0001
Thanks for the review! On Thu, May 21, 2026 at 2:38 PM vellaipandiyan sm <vellaipandiyan.sm@gmail.com> wrote: > > Hello hackers, > > I reviewed the EXPLAIN storage I/O patch and the overall direction seems useful, especially for distinguishing shared-buffer hits from actual storage reads during query analysis. > > One concern that stood out to me from the later discussion is the interaction with asynchronous I/O and worker-based I/O accounting. > > Since the patch currently relies on per-process getrusage() statistics, it seems possible that the reported values could become partial or misleading once I/O is performed outside the backend process context. In particular, worker-based AIO could undercount storage reads/writes while still returning non-zero values, which may make the output appear more accurate than it actually is. Yeah, to avoid reporting the misleadingly underestimated values, no output is shown when worker-based AIO is used, as described in the docs: + ..Also, when + <xref linkend="guc-io-method"/> is set to <literal>worker</literal>, no output + will be shown, as I/O handled by asynchronous workers cannot be measured + accurately. > I also wonder whether this should affect the semantics/documentation of the feature itself — i.e. whether the reported numbers should be described more explicitly as “backend-observed synchronous storage I/O” rather than total query I/O. Updated the patch to clarify that the reported values include not only the backend process executing the query, but also any parallel query worker processes involved in the query. -- Regards, Atsushi Torikoshi