Horton

Re: RFC: Allow EXPLAIN to Output Page Fault Information

Atsushi Torikoshi <torikoshia.tech@gmail.com>

View thread
From: Atsushi Torikoshi <torikoshia.tech@gmail.com>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: torikoshia <torikoshia@oss.nttdata.com>, Pgsql Hackers <pgsql-hackers@postgresql.org>, Tomas Vondra <tomas@vondra.me>
Date: 2026-05-25T12:17:56Z
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 →

  1. Avoid leaking system path from pg_available_extensions

  2. Enable BUFFERS with EXPLAIN ANALYZE by default

On Sun, May 24, 2026 at 6:50 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
>
> On Fri, 22 May 2026 at 18:07, Atsushi Torikoshi
> <torikoshia.tech@gmail.com> wrote:
> > 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.
>
> For PG19 Tomas added an IO option to EXPLAIN. I think it would be
> better to have the Storage IO tracking be enabled by the IO option,
> rather than the BUFFERS option.

Thank you for pointing that out.
I agree that having this under the IO option seems more intuitive.

One thing I am slightly concerned about, though, is that according to
the documentation, the IO option reports only I/O performed by scan
nodes:

> Include information on I/O performed by scan nodes providing such information.

In contrast, the information produced by this patch is based on
getrusage(), so it includes all Storage I/O performed by the backend
and parallel workers, not just scan nodes.
For example, it would also include temporary file I/O generated by
operations such as sorts that spill to disk when they exceed work_mem.

I suppose this could be clarified in the documentation, but I would be
interested to hear if anyone has concerns or objections about that
approach.

--
Regards,
Atsushi Torikoshi