Re: RFC: Allow EXPLAIN to Output Page Fault Information

From: Atsushi Torikoshi <torikoshia(dot)tech(at)gmail(dot)com>
To: vellaipandiyan sm <vellaipandiyan(dot)sm(at)gmail(dot)com>
Cc: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Allow EXPLAIN to Output Page Fault Information
Date: 2026-05-22 16:07:12
Message-ID: CAM6-o=DnHSj2q9_+Wohrvagd-QAqvpoepNRS9LRadMBCkTAMkw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for the review!

On Thu, May 21, 2026 at 2:38 PM vellaipandiyan sm
<vellaipandiyan(dot)sm(at)gmail(dot)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

Attachment Content-Type Size
v11-0001-Add-storage-I-O-tracking-to-BUFFERS-option.patch application/octet-stream 73.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Japin Li 2026-05-22 16:24:54 Re: [PATCH] Add pg_get_policy_ddl() function to reconstruct CREATE POLICY statement
Previous Message Tom Lane 2026-05-22 15:54:04 Re: Rename Postgres 19 to Postgres 26 (year-based)?