Re: RFC: Logging plan of the running query - Mailing list pgsql-hackers

On 2025-04-01 04:24, Robert Haas wrote:
> On Fri, Mar 21, 2025 at 8:40 AM torikoshia <torikoshia@oss.nttdata.com> 
> wrote:
>> Rebased it again.
> 
> Hi,
> 
> I apologize for not having noticed this thread sooner.

Thank you for your checking! No worries.

> I just became
> aware of it as a result of a discussion in the hacking Discord server.

> I think this has got a lot over overlap with the progressive EXPLAIN
> patch from Rafael Castro, which I have been reviewing, but I am not
> sure why we have two different patch sets here. Why is that?

This thread proposes a feature to log the results of a plain EXPLAIN 
(without ANALYZE). From Rafael Castro's presentation materials at 
pgconf.eu 2024 [1], I understand that he built a new patch on top of 
this one, adding functionality to track execution progress and display 
results in a view.
He also mentioned that he used the way of wrapping plan nodes from this 
patch during the development to solve a problem[2].
I think that's why there are overlaps between the two.

Previously, Rafael proposed a patch in this thread that added execution 
progress tracking. However, I felt that expanding the scope could make 
it harder to get the patch reviewed or committed. So, I suggested first 
completing a feature that only retrieves the execution plan of a running 
query, and then developing execution progress tracking afterward[3].

As far as I remember, he did not respond to this thread after my 
suggestion but instead started a new thread later[4]. Based on that, I 
assume he would not have agreed with my proposed approach.

Rafael, please let us know if there are any misunderstandings in the 
above.


In this thread, I aimed to output the plan without requiring prior 
configuration if possible. However, based on your comment on Rafael's 
thread[5], it seems that this approach would be difficult:

   One way in which this proposal seems safer than previous proposals is
   that previous proposals have involved session A poking session B and
   trying to get session B to emit an EXPLAIN on the fly with no prior
   setup. That would be very useful, but I think it's more difficult and
   more risky than this proposal, where all the configuration happens in
   the session that is going to emit the EXPLAIN output.

I was considering whether to introduce a GUC in this patch to allow for 
prior setup before outputting the plan or to switch to Rafael's patch 
after reviewing its details. However, since there isn’t much time left 
before the feature freeze, if you have already reviewed Rafael's patch 
and there is a chance it could be committed, it would be better to focus 
on that.


[1] https://www.youtube.com/watch?v=6ahTb-7C05c (mentions this patch 
after the 12-minute mark)
[2] 
https://www.postgresql.org/message-id/CAG0ozMo30smtXXOR8bSCbhaZAQHo4%3DezerLitpERk85Q0ga%2BFw%40mail.gmail.com
[3] 
https://www.postgresql.org/message-id/c161b5e7e1888eb9c9eb182a7d9dcf89%40oss.nttdata.com
[4] 

https://www.postgresql.org/message-id/flat/CAG0ozMo30smtXXOR8bSCbhaZAQHo4%3DezerLitpERk85Q0ga%2BFw%40mail.gmail.com#4b261994a0d44649ded6e1434a00e134
[5] 
https://www.postgresql.org/message-id/CA%2BTgmoaD985%2BVLwR93c8PjSaoBqxw72Eu7pfBJcArzhjJ71aRw%40mail.gmail.com

-- 
Regards,

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