Re: RFC: Allow EXPLAIN to Output Page Fault Information

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, pgsql-hackers(at)postgresql(dot)org, rjuju123(at)gmail(dot)com, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: RFC: Allow EXPLAIN to Output Page Fault Information
Date: 2025-02-11 08:59:43
Message-ID: CAGECzQTQ+QxR3__5vrHoAoKHs8Uv+c=ZY3_o1FsvXXx4AaRJJQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 11 Feb 2025 at 00:53, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I mostly meant worker based AIO, yes. I haven't checked how accurately these
> > are kept for io_uring. I would hope they are...
>
> It does look like it is tracked.

nice!

> > The thing is that you'd often get completely misleading stats. Some of the IO
> > will still be done by the backend itself, so there will be a non-zero
> > value. But it will be a significant undercount, because the asynchronously
> > executed IO won't be tracked (if worker mode is used).

Yeah, makes sense. Like I said, I would be completely fine with not
showing these numbers at all/setting them to 0 for setups where we
cannot easily get useful numbers (and this bgworker AIO would be one
of those setups).

> Independent to of this, it's probably not good that we're tracking shared
> buffer hits after io combining, if I interpret this correctly... That looks to
> be an issue in master, not just the AIO branch.

You mean that e.g. a combined IO for 20 blocks still sounds only as 1
"shared read"? Yeah, that sounds like a bug.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2025-02-11 09:15:24 Re: Virtual generated columns
Previous Message Коротков Максим 2025-02-11 08:52:29 [PATCH] snowball: fix potential NULL dereference