MIME-Version: 1.0
References: <c20f6340eb26f3b736abc59471bfada8@oss.nttdata.com>
 <CAP53PkyM8uRn9uPrEAmv6UaO+-O0f5VtQFGDWGWC3BD-Zo1UWQ@mail.gmail.com>
 <178013424821.1017.15729495841275970312.pgcf@coridan.postgresql.org>
In-Reply-To: 
 <178013424821.1017.15729495841275970312.pgcf@coridan.postgresql.org>
From: Atsushi Torikoshi <torikoshia.tech@gmail.com>
Date: Mon, 1 Jun 2026 22:10:41 +0900
Message-ID: 
 <CAM6-o=CATBQpDQAa3akuKqw9gWfpN-N7nVr9=8qSejKV+QyHXQ@mail.gmail.com>
Subject: Re: RFC: Allow EXPLAIN to Output Page Fault Information
To: Ilmar Y <tanswis42@gmail.com>, Lukas Fittl <lukas@fittl.com>
Cc: pgsql-hackers@lists.postgresql.org,
	Atsushi Torikoshi <torikoshia@oss.nttdata.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAM6-o%3DCATBQpDQAa3akuKqw9gWfpN-N7nVr9%3D8qSejKV%2BQyHXQ%40mail.gmail.com>
Precedence: bulk

On Tue, May 26, 2026 at 3:44=E2=80=AFAM Lukas Fittl <lukas@fittl.com> wrote=
:

Thanks for your comment!

> Maybe we should try to figure out what would be needed to do better
> I/O tracking on the Linux side in a way that is compatible with I/O
> workers?

That may well be true.
Unfortunately, I do not currently have a good idea of how to achieve
this in a way that works with I/O workers.
 I'll keep thinking about whether there might be another approach.


> e.g. I assume rusage is too expensive to run on individual I/Os that
> the workers process (so its not just a communication problem) -- but
> would be good to benchmark.

Yes, I suspect that would be the case.
Although this is somewhat different from the current discussion, I
once experimented with an implementation that called getrusage() for
each plan node, and the overhead was high enough that it was not
practically usable. [1]


I agree that many users will choose, or be required to choose,
io_method =3D worker. However, there are also users who will continue
to use sync or choose io_uring, so I do not think providing I/O
statistics for those users would be without value.

In particular, from a performance perspective, io_uring seems
likely to be the preferred option in the long run.
In high-performance on-premises environments, for example, it would
not be surprising to see users selecting io_uring.
Those users would also be among those most interested in
understanding how much I/O is being generated against storage,
which is the motivation behind this proposal.


On Sat, May 30, 2026 at 6:45=E2=80=AFPM Ilmar Y <tanswis42@gmail.com> wrote=
:

Thanks for your review!

> The patch applies cleanly on current master at
> db5ed03217b9c238703df8b4b286115d6e940488, but git am warned about trailin=
g
> whitespace.  git diff --check origin/master...HEAD reports:

> src/test/modules/test_misc/t/011_explain_storage_io.pl:47: trailing white=
space
> src/test/modules/test_misc/t/011_explain_storage_io.pl:55: trailing white=
space
> src/test/modules/test_misc/t/011_explain_storage_io.pl:61: trailing white=
space

I'll fix it.

> A second thing I noticed is that, with io_method=3Dsync, structured EXPLA=
IN
> output can show an Execution Storage I/O section even when ANALYZE is not
> used.

We are currently considering moving this functionality to a new IO option t=
hat,
unlike BUFFERS, would require ANALYZE to be specified.[2]

[1] https://www.postgresql.org/message-id/CAGXjcj%3DhnEZCCDDMRv06EQnDcv0mRe=
6%2BPh1gv8%3DHb7NEc51y5A%40mail.gmail.com
[2] https://www.postgresql.org/message-id/CAM6-o%3DBL59LgruKXm3DCjzFzvr7TTJ=
PtryEPj51YeGMFrWO0EQ%40mail.gmail.com

---
Regards,

Atsushi Torikoshi