On 2025-04-03 01:22, Sami Imseih wrote:
>> > FWIW, I have been thinking about auto_explain for another task,
>> > remote plans for fdw [0], and perhaps there are now other good
>> > reasons, some that you mention, that can be simplified if "auto_explain"
>> > becomes a core feature. This could be a proposal taken up in 19.
>>
>> For what we're talking about here, I don't think we would need to go
>> that far -- maybe put a few functions in core but no real need to move
>> the whole module into core. However, I don't rule out that there are
>> other reasons to do as you suggest.
>
> This is the first core feature that will allow users to log explain
> plans for
> a live workload. EXPLAIN is not really good for this purpose. So this
> proposal is a step in the correct direction. I think the appetite for
> more
> plan logging/visibility options will likely increase, and
> auto_explainlike
> features in core will be desired IMO. We will see.
>
> As far as this patch goes, I took a look and I have some comments:
Thanks for your comments!
> 2/
> It should be noted that the plan will not print to the log until
> the plan begins executing the next plan node? depending on the
> operation, that could take some time ( i.e.long seq scan of a table,
> etc.)
> Does this behavior need to be called out in docs?
Seems reasonable, but long seq scan of a table would not cause the case
since ExecProcNode() is called at least the number of the rows in a
table, as far as I remember.
Of course there can be the case where long time can elapse before
executing ExecProcNode(), so I agree with adding the doc about this.
I'm going to improve including other than this comment in the next
patch.
--
Regards,
--
Atsushi Torikoshi
Seconded from NTT DATA GROUP CORPORATION to SRA OSS K.K.
