Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1miJUu-0004vw-Do for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Nov 2021 16:52:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1miJUs-0005s9-A9 for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Nov 2021 16:52:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1miJUs-0005s0-1a for pgsql-hackers@lists.postgresql.org; Wed, 03 Nov 2021 16:52:22 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1miJUp-0003Gs-K2 for pgsql-hackers@postgresql.org; Wed, 03 Nov 2021 16:52:21 +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 1A3GqG7x134558; Wed, 3 Nov 2021 12:52:16 -0400 From: Tom Lane To: Robert Haas cc: James Coleman , pgsql-hackers , Amit Kapila Subject: Re: Parallelize correlated subqueries that execute within each worker In-reply-to: References: <8701.1635952475@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Wed, 03 Nov 2021 12:27:42 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <134556.1635958336.1@sss.pgh.pa.us> Date: Wed, 03 Nov 2021 12:52:16 -0400 Message-ID: <134557.1635958336@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > One thing I discovered when I was looking at this a few years ago is > that there was only one query in the regression tests where extParam > and allParam were not the same. The offending query was select 1 = > all(select (select 1)), and the resulting plan has a Materialize node > with an attached InitPlan. For that Materialize node, extParam = {} > and allParam = {$0}, with $0 also being the output parameter of the > InitPlan attached that that Materialize node. In every other node in > that plan and in every node of every other plan generated by the > regression tests, the values were identical. So it's extremely niche > that these fields are even different from each other, and it's unclear > to me that we really need both of them. Yeah, I've had that nagging feeling about them too. But ISTR trying to reduce them to one value years ago, and finding that it didn't quite work, or at least would result in more subquery-re-evaluation than we do today. You have to dig into what the executor uses these values for to really grok them. I'm afraid that that detail is all swapped out right now, so I can't say much more. regards, tom lane