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 1q05B6-0005Pb-Pc for pgsql-bugs@arkaria.postgresql.org; Fri, 19 May 2023 18:50:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q05B5-0005Ne-Ca for pgsql-bugs@arkaria.postgresql.org; Fri, 19 May 2023 18:50:11 +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 1q05B5-0005NV-4N for pgsql-bugs@lists.postgresql.org; Fri, 19 May 2023 18:50:11 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q05B2-000mDg-5k for pgsql-bugs@lists.postgresql.org; Fri, 19 May 2023 18:50:10 +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 34JIo5vk288017; Fri, 19 May 2023 14:50:05 -0400 From: Tom Lane To: Richard Guo cc: Robert Haas , Andrey Lepikhov , PostgreSQL mailing lists Subject: Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware) In-reply-to: References: <0b819232-4b50-f245-1c7d-c8c61bf41827@postgrespro.ru> <402433.1677524538@sss.pgh.pa.us> <2663884e-769a-b298-55b0-014c5a1ee55c@postgrespro.ru> <524303.1677538463@sss.pgh.pa.us> <999171.1677611407@sss.pgh.pa.us> <1526312.1683912310@sss.pgh.pa.us> <27! 66442.1684265014@sss.pgh.pa.us> <3014965.1684293045@sss.pgh.pa.us> <3344781.1684337332@sss.pgh.pa.us> <3732983.1684416513@sss.pgh.pa.us> Comments: In-reply-to Richard Guo message dated "Fri, 19 May 2023 15:34:47 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <288015.1684522205.1@sss.pgh.pa.us> Date: Fri, 19 May 2023 14:50:05 -0400 Message-ID: <288016.1684522205@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > Take the query shown upthread as an example, which would trigger an > Assert. > create table t (a int unique, b int); > explain (costs off) > select 1 from t t1 > left join (t t2 left join t t3 on t2.a = 1) on t2.a = 1; > server closed the connection unexpectedly > We'd be mistaken to think t1/t2 join is removable, because we are > checking its syntactic relid set, which includes all rels, and so that > are not aware that t2.a is used by t2/t3 join. Ah, now your point has finally penetrated my thick skull: we can't remove a join if its output is referenced at any join level that we could potentially postpone past the join of interest, even when that join is syntactically below it. It seems like there might be more than one way to skin that cat; maybe we could remove it anyway and restrict the join order later? But I agree that three days before beta isn't the time to be rethinking the join removal rules. I remembered why it was that I wanted to change this logic, though. It wasn't totally clear to me that min_lefthand + min_righthand would account properly for outer joins below the one of interest. However, considering it now it seems like that will hold, so now I think your patch is correct. regards, tom lane