Horton

Re: RFC: Allow EXPLAIN to Output Page Fault Information

torikoshia <torikoshia@oss.nttdata.com>

View thread
From: torikoshia <torikoshia@oss.nttdata.com>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: andres@anarazel.de, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org, rjuju123@gmail.com, Bruce Momjian <bruce@momjian.us>
Date: 2025-03-25T01:27:31Z
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

On 2025-03-22 20:23, Jelte Fennema-Nio wrote:

> On Wed, 19 Mar 2025 at 14:15, torikoshia <torikoshia@oss.nttdata.com> 
> wrote:
>> BTW based on your discussion, I thought this patch could not be merged
>> anytime soon. Does that align with your understanding?
> 
> Yeah, that aligns with my understanding. I don't think it's realistic
> to get this merged before the code freeze, but I think both of the
> below issues could be resolved.
> 
>> - With bgworker-based AIO, this patch could mislead users into
>> underestimating the actual storage I/O load, which is undesirable.
> 
> To resolve this, I think the patch would need to change to not report
> anything if bgworker-based AIO is used.

Agreed.
I feel the new GUC io_method can be used to determine whether 
bgworker-based AIO is being used.

> So I moved this patch to the
> next commitfest, and marked it as "waiting for author" there.

Thanks for moving it.

>> - With io_uring-based AIO, this patch could provide meaningful values,
>> but it may take some time before io_uring sees widespread adoption.
> 
> I submitted this patch to help make io_uring-based AIO more of a 
> reality:
> https://commitfest.postgresql.org/patch/5570/

Thanks for working on that, too.

-- 
Regards,

--
Atsushi Torikoshi
Seconded from NTT DATA GROUP CORPORATION to SRA OSS K.K.