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 1rV1Mp-00ENuo-Ns for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Jan 2024 03:34:28 +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 1rV1Mo-00B1Te-S4 for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Jan 2024 03:34:26 +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 1rV1Mo-00B1TW-Ic for pgsql-hackers@lists.postgresql.org; Wed, 31 Jan 2024 03:34:26 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rV1Mi-004dSJ-07 for pgsql-hackers@postgresql.org; Wed, 31 Jan 2024 03:34:25 +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 40V3Y1892380557; Tue, 30 Jan 2024 22:34:01 -0500 From: Tom Lane To: James Coleman cc: vignesh C , Richard Guo , Tomas Vondra , Andres Freund , Robert Haas , pgsql-hackers , Amit Kapila Subject: Re: Parallelize correlated subqueries that execute within each worker In-reply-to: References: <20220322004805.vwmgjp62tq3mj2oq@alap3.anarazel.de> <1818a285-59b9-e028-c5a8-539f715b9371@enterprisedb.com> Comments: In-reply-to James Coleman message dated "Tue, 30 Jan 2024 21:51:09 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2380555.1706672041.1@sss.pgh.pa.us> Date: Tue, 30 Jan 2024 22:34:01 -0500 Message-ID: <2380556.1706672041@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk James Coleman writes: > I've finally had a chance to look at this, and I don't believe there's > any real failure here, merely drift of how the planner works on master > resulting in this query now being eligible for a different plan shape. > I was a bit wary at first because the changing test query is one I'd > previously referenced in [1] as likely exposing the bug I'd fixed > where params where being used across worker boundaries. However > looking at the diff in the patch at that point (v10) that particular > test query formed a different plan shape (there were two gather nodes > being created, and params crossing between them). > But in the current revision of master with the current patch applied > that's no longer true: we have a Gather node, and the Subplan using > the param is properly under that Gather node, and the param should be > being both generated and consumed within the same worker process. Hmm ... so the question this raises for me is: was that test intended to verify behavior of params being passed across workers? If so, haven't you broken the point of the test? This doesn't mean that your code change is wrong; but I think maybe you need to find a way to modify that test case so that it still tests what it's meant to. This is a common hazard when changing the planner's behavior. regards, tom lane