public inbox for [email protected]  

help / color / mirror / Atom feed

From: torikoshia <[email protected]>
To: Andrei Lepikhov <[email protected]>
Cc: Lukas Fittl <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: [email protected]
Cc: Atsushi Torikoshi <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: RFC: Logging plan of the running query
Date: Tue, 07 Jul 2026 23:46:25 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAP53Pkw8CX0RQY474McHyc1N8p331-asEBAEGu0X+bJX-VB8jg@mail.gmail.com>
	<[email protected]>
	<CA+TgmobUqXfn9Y40Oc0PKn7yeG62v8gwAekr=HUQjcW3OPAk5Q@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CA+TgmoZQCVNqR9JnzTPEKAr85Q91L9odhmqGEZuJ6x4V5FJ-ig@mail.gmail.com>
	<[email protected]>
	<CA+TgmoYS7BzX3Zu+A-ZGd026q5nyC5cctjiVeZNwj1eYSqoOaQ@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On 2026-07-06 22:05, Andrei Lepikhov wrote:
> On 06/07/2026 08:21, torikoshia wrote:
>> On Wed, Jul 1, 2026 at 7:42 PM Andrei Lepikhov <[email protected]> 
>> wrote:
>> 
>>> I’d
>>> propose introducing a tiny hook (register callback?) into 
>>> ExecProcNode() and
>>> just setting it in ProcessLogQueryPlanInterrupt.
>> 
>> This approach would also be possible, but we are concerned that
>> checking the hook on every ExecProcNode() call would add too much
>> overhead and could have a significant performance impact.
> 
> I doubt the performance impact, but generally agree: having
> ExecSetExecProcNode/ExecProcNodeFirst trick with a one-time callback 
> inside
> (right now it is the only hard-wired LogQueryPlan call) may be enough 
> for the
> implementation.
> 
> So, the extendable part here may be an ExecProcNodeFirst callback that 
> an
> extension module can register once (for example, before the start of an 
> EXPLAIN
> ANALYZE) or re-arm on each call of such 'execution state probes'.
> 
>>> Maybe the next call to ExecProcNode() will be made
>>> from an external query (or from a deeper one).
>>> The current implementation will
>>> not produce any EXPLAIN in this case, but query still executes.
>> 
>> That said, I think a similar situation can still occur if execution
>> moves to an external or deeper queryDesc after the individual plan
>> nodes have been wrapped. In that case, the plan does not be logged
>> even though the query continues executing.
> 
> That's the problem.

Sorry, I misremembered the logic.
In this case, even if execution moves to an external or deeper
QueryDesc, LogQueryPlanPending flag remains set. Therefore, the plan
tree for that external or deeper QueryDesc will be wrapped, and
the plan will be logged.

For example, with the following query, ExecProcNode() is called four 
times:

CREATE OR REPLACE FUNCTION f1() RETURNS void AS $$
BEGIN
     PERFORM 1;
END;
$$ LANGUAGE plpgsql;

SELECT f1();

If pg_log_query_plan() is called just after the first
ExecProcNode() call reaches ExecProcNodeFirst(), the plan for PERFORM 1
is logged.


Thanks,

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

view thread (127+ messages)

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], [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