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 1qlkZj-004CYn-EG for pgsql-bugs@arkaria.postgresql.org; Thu, 28 Sep 2023 06:32:39 +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 1qlkZh-009Wte-Bb for pgsql-bugs@arkaria.postgresql.org; Thu, 28 Sep 2023 06:32:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlkZh-009WtQ-2Y for pgsql-bugs@lists.postgresql.org; Thu, 28 Sep 2023 06:32:37 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by magus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qlkZa-0082OA-MK for pgsql-bugs@lists.postgresql.org; Thu, 28 Sep 2023 06:32:37 +0000 Received: from [172.30.8.38] (unknown [172.30.8.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: a.lepikhov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id 241FEE2102D; Thu, 28 Sep 2023 09:32:27 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1695882749; bh=qAttP9o7ufZil1i8zxzcc1MUFzaOcy3COj/srkmZvwo=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=EyUGz3A7/kYkDoFDkr1amv/b4PUxCxPBs0a3Nzx2qkyYxymAL4D0PL7HCezrQAx98 jbbPbYqaFQGDNiJ277JKb9KF5E4P4M/EaIuNETOPr1Fou29IwXIaVInG7fDDw8yM64 siSpXwUWGgAGBkdj5UKeHyUpEP6VDPui9jrL8vBWg+kA7sH/0bsViTGizWdO3buxBw 7cfTw5PGSgk8B+gTciw8nbHif6hnBwgW/bFl4ICL9YFxx7PXTsXhQX/izCJC+0H6jd MNtFXoedVFiBmIHj1H/uCtHQTYWXavjAw571xDo5d/mRlyn5Nuqqw55MqX/ivL2kw4 GC3glzYhDy4yg== Message-ID: Date: Thu, 28 Sep 2023 13:32:25 +0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: EXPLAIN Verbose issue - custom_scan_tlist can directly refer CTE and Subquery Content-Language: en-US To: Richard Guo , Lepikhov Andrei Cc: pgsql-bugs@lists.postgresql.org, tgl@sss.pgh.pa.us, =?UTF-8?B?0JDQu9C10L3QsCDQoNGL0LHQsNC60LjQvdCw?= , =?UTF-8?B?0JTQsNC80LjRgCDQkdC10LvRj9C70L7Qsg==?= References: From: Andrey Lepikhov Organization: Postgres Professional In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 11/9/2023 13:28, Richard Guo wrote: > So it seems that we need to assign a proper INNER referent for > CustomScan node in set_deparse_plan().  I tried 'trick.diff' in [1] > which uses linitial(dpns->subplans), it fixes the query there but would > crash the query below. > > explain (verbose, costs off) > select (rr).column2 from >   (select r from (values(1,2),(3,4)) r) s join >   (select rr from (values(1,7),(3,8)) rr limit 2) ss >   on (r).column1 = (rr).column1; > server closed the connection unexpectedly > > Maybe we can use the first plan in CustomScan->custom_plans as the INNER > referent?  I'm not sure. Looking into this issue more, I figured out that we can't be sure from which side the current varno of custom_scan_tlist was produced: from inner, outer or one of the custom subplans. In one of my previous R&D projects, I remember that the CustomScan node received tuples from the network, gathering them from other pg-instances. So, as we already have an optional ExplainCustomScan routine, maybe add one more for the show_plan_tlist routine? It can print a target list or ignore it as the Append node does. -- regards, Andrey Lepikhov Postgres Professional