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 1rvJAP-00B95j-8j for pgsql-bugs@arkaria.postgresql.org; Fri, 12 Apr 2024 15:50:17 +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 1rvJAN-00FiGY-KJ for pgsql-bugs@arkaria.postgresql.org; Fri, 12 Apr 2024 15:50:15 +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 1rvJAN-00FiGQ-Bx for pgsql-bugs@lists.postgresql.org; Fri, 12 Apr 2024 15:50:15 +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 1rvJAG-000Zbm-Iu for pgsql-bugs@lists.postgresql.org; Fri, 12 Apr 2024 15:50:14 +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 43CFo2Nc450118; Fri, 12 Apr 2024 11:50:02 -0400 From: Tom Lane To: Benoit Ryder cc: "David G. Johnston" , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #18429: Inconsistent results on similar queries with join lateral In-reply-to: References: <18429-8982d4a348cc86c6@postgresql.org> <441100.1712933417@sss.pgh.pa.us> Comments: In-reply-to Benoit Ryder message dated "Fri, 12 Apr 2024 15:33:41 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <450116.1712937002.1@sss.pgh.pa.us> Date: Fri, 12 Apr 2024 11:50:02 -0400 Message-ID: <450117.1712937002@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Benoit Ryder writes: > Would you know a way to avoid this bug? I could probably tweak the query > until the result is looking good, but I would prefer to make sure the > bug won't reappear if the query is used with different data or context. I'm not seeing a bulletproof way offhand, other than "update to v16". Disabling nestloop plans fixes your Q4 in the back branches, but not Q1 (because there's no opportunity for a hash or merge join in Q1). It looks like the problem is that the old join_clause_is_movable logic is incorrectly deciding that the WHERE condition can be pushed down to the sub-select relation. So we should be able to fix it there, but I'm not sure how messy that will be or whether we'll lose the ability to generate some correct plans. It's hard to justify putting a huge amount of work into old branches though. regards, tom lane