public inbox for pgsql-hackers@postgresql.org  

help / color / mirror / Atom feed

From: Bruce Momjian <bruce@momjian.us>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: torikoshia <torikoshia@oss.nttdata.com>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: RFC: Allow EXPLAIN to Output Page Fault Information
Date: Mon, 30 Dec 2024 11:19:47 -0500
Message-ID: <Z3LII9YEgp3kAZG-@momjian.us> (raw)
In-Reply-To: <D6MJOHS7HZ80.3B17NDGUV6T47@jeltef.nl>
References: <c20f6340eb26f3b736abc59471bfada8@oss.nttdata.com>
	<1614321.1735055528@sss.pgh.pa.us>
	<D6MJOHS7HZ80.3B17NDGUV6T47@jeltef.nl>

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@oss.nttdata.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.
> > 
> > Surely these numbers would be too unstable to be worth anything.
> 
> What makes you think that? I'd expect them to be similarly stable to the
> numbers we get for BUFFERS. i.e. Sure they won't be completely stable,
> but I expect them to be quite helpful when debugging perf issues,
> because large numbers indicate that the query is disk-bound and small
> numbers indicate that it is not.
> 
> These numbers seem especially useful for setups where shared_buffers is
> significantly smaller than the total memory available to the system. In
> those cases the output from BUFFERS might give the impression that that
> you're disk-bound, but if your working set still fits into OS cache then
> the number of page faults is likely still low. Thus telling you that the
> numbers that you get back from BUFFERS are not as big of a problem as
> they might seem.

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

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: bruce@momjian.us, postgres@jeltef.nl, tgl@sss.pgh.pa.us, torikoshia@oss.nttdata.com
  Subject: Re: RFC: Allow EXPLAIN to Output Page Fault Information
  In-Reply-To: <Z3LII9YEgp3kAZG-@momjian.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox