Re: RFC: Logging plan of the running query
torikoshia <torikoshia@oss.nttdata.com>
From: torikoshia <torikoshia@oss.nttdata.com>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Lukas Fittl <lukas@fittl.com>, Robert Haas <robertmhaas@gmail.com>,
pgsql-hackers@lists.postgresql.org, Atsushi Torikoshi
<torikoshia.tech@gmail.com>, samimseih@gmail.com, destrex271@gmail.com
Date: 2026-07-07T14:46:25Z
Lists: pgsql-hackers
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 <lepihov@gmail.com>
>> 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.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
ecpg: Catch zero-length Unicode identifiers correctly
- a18b6d2dc288 15.0 cited
-
Improve warning message in pg_signal_backend()
- 7fa945b857cc 15.0 cited
-
Add assert to ensure that page locks don't participate in deadlock cycle.
- 72e78d831ab5 13.0 cited