public inbox for [email protected]
help / color / mirror / Atom feedFrom: torikoshia <[email protected]>
To: Sami Imseih <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: RFC: Logging plan of the running query
Date: Thu, 03 Apr 2025 14:59:02 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA5RZ0vyREmzjh4-PgGUSLSvvjR2TZf3g4AjhACepbA5qfrL5Q@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<174144854199.294105.9417032645816235284.pgcf@coridan.postgresql.org>
<[email protected]>
<[email protected]>
<CA+TgmoatMzMedKRYAK5s3euxUohd6m00szL4Q6GGQj+NhF813A@mail.gmail.com>
<CAA5RZ0uTBLX6=M3y6zEmOrQtmS5=UDWD3-=vRFuaLpg1v6bpiw@mail.gmail.com>
<CA+TgmobQCaYFQyrXLBeTvdeUugCiEcOiBEB2AwVhXfpbMe5fEw@mail.gmail.com>
<CAA5RZ0vyREmzjh4-PgGUSLSvvjR2TZf3g4AjhACepbA5qfrL5Q@mail.gmail.com>
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.
view thread (127+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: RFC: Logging plan of the running query
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox