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 1pz0Gx-0004tX-6L for pgsql-bugs@arkaria.postgresql.org; Tue, 16 May 2023 19:23:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pz0Gu-0006Nb-Nh for pgsql-bugs@arkaria.postgresql.org; Tue, 16 May 2023 19:23:44 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pz0Gu-0006NR-FM for pgsql-bugs@lists.postgresql.org; Tue, 16 May 2023 19:23:44 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pz0Gn-000B4Q-Bo for pgsql-bugs@lists.postgresql.org; Tue, 16 May 2023 19:23:42 +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 34GJNYAF2766443; Tue, 16 May 2023 15:23:34 -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> <2489296.1684195396@sss.pgh.pa.us> Comments: In-reply-to Richard Guo message dated "Tue, 16 May 2023 14:22:42 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2766441.1684265014.1@sss.pgh.pa.us> Date: Tue, 16 May 2023 15:23:34 -0400 Message-ID: <2766442.1684265014@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > I doubt this is always right to add joins_below to all the vars > belonging to sjinfo->syn_lefthand. What if the joins in joins_below > cannot commute with each other? As a counterexample, consider the query > below which causes assertion failure in search_indexed_tlist_for_var. > The query is designed so that t1/t2 join cannot commute with t2/t3 join > but can commute with t3/t4 join. > explain (costs off) > select * from t t1 > left join t t2 on true > left join t t3 on true > left join t t4 on t2.a = t3.a; Hm. Actually, t1/t2 *can't* commute with the t4 join. You can re-order the t2 and t3 joins per identity 2: select * from t t1 left join t t3 on true left join t t2 on true left join t t4 on t2.a = t3.a; but you're still stuck, identity 3 applies nowhere (because in either case, the putative Pbc clause has also got a reference to A). make_outerjoininfo is setting the t4 join's commute_below_l to include t1/t2, but it seems to me that that indicates inadequate analysis in make_outerjoininfo. Is there still a problem here if we get rid of that overoptimistic conclusion? We should strive to do so even if it's not fixing an observable problem, because in any case it's causing the planner to waste time on unreachable join orders. regards, tom lane