Re: RFC: Allow EXPLAIN to Output Page Fault Information

From: Jeremy Schneider <schneider(at)ardentperf(dot)com>
To: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Allow EXPLAIN to Output Page Fault Information
Date: 2024-12-26 19:52:11
Message-ID: 20241226115211.676ba09a@jeremy-ThinkPad-T430s
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 26 Dec 2024 13:15:59 +0900
torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> wrote:

> On 2024-12-25 00:52, 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.
> >
> > Surely these numbers would be too unstable to be worth anything.
>
> Thanks for your comment!
>
> Hmm, I didn't know these are unstable. If there are any reasons, I'd
> like to know about them.
>
> I would like to explore alternative methods for measuring resource
> usage, but
> I am not aware of other approaches.
> (IIUC pg_stat_kcache[1], which is said to provide information about
> filesystem layer I/O usage also gets metrics from getrusage(2))

What I'd really like to see is a column added to pg_stat_database
called blks_read_majflts

It would be great if we could calculate a cache hit ratio that took OS
major page faults into account

Yes this could also be done in pg_stat_kcache but why not do it right
in pg_stat_database? I think it would pretty widely appreciated and
used.

-Jeremy

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2024-12-26 21:53:51 Re: Removing unused parameter in compute_expr_stats
Previous Message Bruce Momjian 2024-12-26 19:26:51 Re: attndims, typndims still not enforced, but make the value within a sane threshold