From: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Étienne BERSAC <etienne(dot)bersac(at)dalibo(dot)com> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, jtc331(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: RFC: Logging plan of the running query |
Date: | 2023-10-24 12:30:49 |
Message-ID: | 66d29d2c10ca9181c7e183eeeb4525f8@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2023-10-24 16:12, Étienne BERSAC wrote:
>> Hi,
>>
>> Yeah, and when we have a situation where we want to run
>> pg_log_query_plan(), we can run it in any environment as long as it
>> is bundled with the core.
>
> Is it possible to get the plan of a backend programmatically without
> access to the logs?
>
> Something like pg_get_query_plan(pid, format) which output would be the
> same as EXPLAIN.
Do you imagine a function like below?
=# select pg_get_query_plan(100, 'plain');
QUERY PLAN
-------------------------------------------------------------------
Limit (cost=0.00..0.04 rows=1 width=273)
-> Seq Scan on pg_class (cost=0.00..17.14 rows=414 width=273)
If so, we once tried to implement such function for getting memory
contexts.
However, this attempt didn't succeed because it could lead dead lock
situation[1].
I think the same problem can occur when implementing
pg_get_query_plan().
[1]
https://www.postgresql.org/message-id/9a50371e15e741e295accabc72a41df1%40oss.nttdata.com
>
> Regards,
> Étienne BERSAC
> Dalibo
--
Regards,
--
Atsushi Torikoshi
NTT DATA Group Corporation
From | Date | Subject | |
---|---|---|---|
Next Message | Crisp Lee | 2023-10-24 12:33:38 | make pg_ctl start more friendly |
Previous Message | Robert Haas | 2023-10-24 12:29:49 | Re: trying again to get incremental backup |