Re: RFC: Allow EXPLAIN to Output Page Fault Information

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, 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: 2024-12-30 16:39:24
Message-ID: 3861403.1735576764@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Fri, Dec 27, 2024 at 03:15:40PM +0100, Jelte Fennema-Nio wrote:
>> On Tue Dec 24, 2024 at 4:52 PM CET, Tom Lane wrote:
>>> torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> writes:
>>>> I have attached a PoC patch that modifies EXPLAIN to include page
>>>> fault information during both the planning and execution phases of a
>>>> query.

> I certainly would love to see storage I/O numbers as distinct from
> kernel read I/O numbers.

Me too, but I think it is 100% wishful thinking to imagine that
page fault counts match up with that. Maybe there are filesystems
where a read that we request maps one-to-one with a subsequent
page fault, but it hardly seems likely to me that that's
universal. Also, you can't tell page faults for reading program
code apart from those for data, and you won't get any information
at all about writes.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2024-12-30 17:01:20 Re: Memory leak in pg_logical_slot_{get,peek}_changes
Previous Message Greg Sabino Mullane 2024-12-30 16:37:14 Re: Proposal: Progressive explain