MIME-Version: 1.0
References: <CAM6-o=BE=oewSsdNKrbbNjR2muzQR49STXsuta+Wpq6CSyxTag@mail.gmail.com>
 <2c9d6eaf26df17bec13bb03bf1e9bcbb@oss.nttdata.com> <CAGECzQRvcLx44N3zd_DGCjY02XX4AqXX8mq4BiS8C9Froy+Jhg@mail.gmail.com>
 <CAGECzQQdc-k=M2fMCKa98kVZntc=6d3rpd6edt8Qs45cayfUeQ@mail.gmail.com>
 <myw76agwrlmisvamwbfl6ibxgwh5glzitydiwnfmtb5aui232i@274yxxtnbnsp>
 <2035079.1739124342@sss.pgh.pa.us> <CAGECzQTm6oEEY4yO_FO0ZBtUuJX+pYiXhw2GPPRMzq_5DP5_fQ@mail.gmail.com>
 <edvo7bpgi7rcthj7btsduleep4j6dcnsx3a2aqrwmybetttmkw@g5chr66cckg6>
 <CAGECzQTydZ33miLd=KdbfrV17RowRGBwQrS28hZ0i6+YhetYgg@mail.gmail.com>
 <mzjytadtjqv4knvwukppaol5zx2qzt2bkuqvjlo4rjawvhn4ql@qmdf64qkmxjo> <dfnb7me4hsbdb6mxlosxcfvh4xjdk5qoy42piuu2ahblwmocyf@ma3bh552myoe>
In-Reply-To: <dfnb7me4hsbdb6mxlosxcfvh4xjdk5qoy42piuu2ahblwmocyf@ma3bh552myoe>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
Date: Tue, 11 Feb 2025 09:59:43 +0100
Message-ID: <CAGECzQTQ+QxR3__5vrHoAoKHs8Uv+c=ZY3_o1FsvXXx4AaRJJQ@mail.gmail.com>
Subject: Re: RFC: Allow EXPLAIN to Output Page Fault Information
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, torikoshia <torikoshia@oss.nttdata.com>, 
	pgsql-hackers@postgresql.org, rjuju123@gmail.com, 
	Bruce Momjian <bruce@momjian.us>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAGECzQTQ%2BQxR3__5vrHoAoKHs8Uv%2Bc%3DZY3_o1FsvXXx4AaRJJQ%40mail.gmail.com>
Precedence: bulk

On Tue, 11 Feb 2025 at 00:53, Andres Freund <andres@anarazel.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.