Re: RFC: Allow EXPLAIN to Output Page Fault Information

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
Cc: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, tgl(at)sss(dot)pgh(dot)pa(dot)us, Bruce Momjian <bruce(at)momjian(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Allow EXPLAIN to Output Page Fault Information
Date: 2025-01-06 09:59:02
Message-ID: Z3upZkA5Bi6lYS6a@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Jan 06, 2025 at 06:49:06PM +0900, torikoshia wrote:
>
> > **However, I think the general direction has merit**: Changing this
> > patch to
> > use `ru_inblock`/`ru_oublock` gives very useful insights. `ru_inblock`
> > is 0 when everything is in page cache, and it is very high when stuff is
> > not. I was only hacking around and basically did this:
> >
> > s/ru_minflt/ru_inblock/g
> > s/ru_majflt/ru_oublock/g
> > [...]
> > Also, maybe there's some better way
> > of getting read/write numbers for the current process than
> > ru_inblock/ru_oublock (but this one seems to work at least reasonably
> > well).
>
> Maybe, but as far as using getrusage(), ru_inblock and ru_outblock seem the
> best.

FWIW that's the counters we've been using in pg_stat_kcache / powa to compute
disk IO and "postgres shared buffers hit VS OS cache hit VS disk read" hit
ratio for many years and we didn't get any problem report for that.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2025-01-06 10:01:17 Re: Re: proposal: schema variables
Previous Message Kohei Harikae (Fujitsu) 2025-01-06 09:57:58 RE: Windows meson build