Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qvGYk-004GPB-5N for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Oct 2023 12:30:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qvGYi-006lUc-6W for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Oct 2023 12:30:56 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qvGYh-006lUO-TW for pgsql-hackers@lists.postgresql.org; Tue, 24 Oct 2023 12:30:56 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qvGYf-0024Em-Cn for pgsql-hackers@lists.postgresql.org; Tue, 24 Oct 2023 12:30:55 +0000 Received: from oss.nttdata.com (localhost [127.0.0.1]) by oss.nttdata.com (Postfix) with ESMTPA id 1CD13601E7; Tue, 24 Oct 2023 21:30:49 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at oss.nttdata.com MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 24 Oct 2023 21:30:49 +0900 From: torikoshia To: =?UTF-8?Q?=C3=89tienne_BERSAC?= Cc: Ashutosh Bapat , Andres Freund , jtc331@gmail.com, pgsql-hackers@lists.postgresql.org Subject: Re: RFC: Logging plan of the running query In-Reply-To: <9c36599db62ef7466a297843fe812fc60e827cd2.camel@dalibo.com> References: <4e1e4e5d022964953e84468fe4e511b0@oss.nttdata.com> <4af7712833d4ce989cf5e658106e42da@oss.nttdata.com> <7ab57ab0ba3416e2dbf54927752bc310@oss.nttdata.com> <20231006155850.kjjb2vwbkawj7moq@alap3.anarazel.de> <0e0e7ca08dff077a625c27a5e0c2ef0a@oss.nttdata.com> <2d6d7846b6b794c0e727c431852a113c@oss.nttdata.com> <0eb66e8c72f23695957466db5c76c69c@oss.nttdata.com> <9c36599db62ef7466a297843fe812fc60e827cd2.camel@dalibo.com> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <66d29d2c10ca9181c7e183eeeb4525f8@oss.nttdata.com> X-Sender: torikoshia@oss.nttdata.com List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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