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 1rl90y-000M7k-K6 for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Mar 2024 14:58:33 +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 1rl90w-009nP7-M7 for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Mar 2024 14:58:31 +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 1rl90w-009nOy-Cs for pgsql-hackers@lists.postgresql.org; Fri, 15 Mar 2024 14:58:30 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rl90s-004f2X-Ur for pgsql-hackers@lists.postgresql.org; Fri, 15 Mar 2024 14:58:29 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 42FEwPV52506270; Fri, 15 Mar 2024 10:58:25 -0400 From: Tom Lane To: Dean Rasheed cc: Aleksander Alekseev , pgsql-hackers@lists.postgresql.org, Chantal Keller Subject: Re: Improving EXPLAIN's display of SubPlan nodes In-reply-to: References: <2838538.1705692747@sss.pgh.pa.us> <3791430.1705943243@sss.pgh.pa.us> <3831858.1705959108@sss.pgh.pa.us> <3511300.1708112330@sss.pgh.pa.us> Comments: In-reply-to Dean Rasheed message dated "Sat, 09 Mar 2024 13:07:40 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2506268.1710514705.1@sss.pgh.pa.us> Date: Fri, 15 Mar 2024 10:58:25 -0400 Message-ID: <2506269.1710514705@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Dean Rasheed writes: > One thing that concerns me about making even greater use of "$n" is > the potential for confusion with generic plan parameters. True. > Another possibility is to put the SubPlan and InitPlan names inline, > rather than outputting "FROM SubPlan ...". I had a go at hacking that > up and this was the result: > Output: (($3 = (InitPlan 1).$0) AND ($4 = (InitPlan 1).$1) AND > ((($1 = (SubPlan 2).$3) AND ($2 = (SubPlan 2).$4)))) Hmm. I guess what bothers me about that is that it could be read to suggest that the initplan or subplan is evaluated again for each output parameter. Perhaps it'll be sufficiently clear as long as we keep the labeling > InitPlan 1 (returns $0,$1) > SubPlan 2 (returns $3,$4) but I'm not sure. Anybody else have an opinion? (I didn't read your changes to the code yet --- I think at this point we can just debate proposed output without worrying about how to implement it.) regards, tom lane