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
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 |