Re: RFC: Allow EXPLAIN to Output Page Fault Information

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
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>
Date: 2025-02-10T13:31:38Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Avoid leaking system path from pg_available_extensions

  2. Enable BUFFERS with EXPLAIN ANALYZE by default

Hi,

On 2025-02-09 21:06:02 +0100, Jelte Fennema-Nio wrote:
> On Sun, 9 Feb 2025 at 19:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > Andres Freund <andres@anarazel.de> writes:
> > > I'm somewhat against this patch, as it's fairly fundamentally incompatible
> > > with AIO. There's no real way to get information in this manner if the IO
> > > isn't executed synchronously in process context...
> 
> Hmm, I had not considered how this would interact with your AIO work.
> I agree that getting this info would be hard/impossible to do
> efficiently, when IOs are done by background IO processes that
> interleave IOs from different queries. But I'd expect that AIOs that
> are done using iouring would be tracked correctly without having to
> change this code at all (because I assume those are done from the
> query backend process).
> 
> One other thought: I think the primary benefit of this feature is
> being able to see how many read IOs actually hit the disk, as opposed
> to hitting OS page cache. That benefit disappears when using Direct
> IO, because then there's no OS page cache.
> 
> How many years away do you think that widespread general use of
> AIO+Direct IO is, though?

I think it'll always be a subset of use. It doesn't make sense to use DIO for
a small databases or untuned databases. Or a system that's deliberately
overcommmitted.

But this will also not work with AIO w/ Buffered IO. Which we hope to use much
more commonly.

If suddenly I have to reimplement something like this to work with worker
based IO, it'll certainly take longer to get to AIO.

Greetings,

Andres Freund