Re: RFC: Logging plan of the running query

On 2025-04-01 04:24, Robert Haas wrote:
> On Fri, Mar 21, 2025 at 8:40 AM torikoshia <torikoshia(at)oss(dot)nttdata(dot)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.