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 1pzdgO-0007lP-Gk for pgsql-bugs@arkaria.postgresql.org; Thu, 18 May 2023 13:28:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pzdgM-0001kt-Fu for pgsql-bugs@arkaria.postgresql.org; Thu, 18 May 2023 13:28:38 +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 1pzdgM-0001kj-7T for pgsql-bugs@lists.postgresql.org; Thu, 18 May 2023 13:28:38 +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 1pzdgJ-000XXs-2E for pgsql-bugs@lists.postgresql.org; Thu, 18 May 2023 13:28:37 +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 34IDSXn23732984; Thu, 18 May 2023 09:28:33 -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> <2766442.1684265014@sss.pgh.pa.us> <3014965.1684293045@sss.pgh.pa.us> <3344781.1684337332@sss.pgh.pa.us> Comments: In-reply-to Richard Guo message dated "Thu, 18 May 2023 16:58:21 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3732982.1684416513.1@sss.pgh.pa.us> Date: Thu, 18 May 2023 09:28:33 -0400 Message-ID: <3732983.1684416513@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > BTW, it seems that there is a minor thinko in the changes. In the > outer-join removal logic, we use syn_xxxhand to compute the relid set > for the join we are considering to remove. I think this might be not > right, because the outer joins may not be performed in syntactic order. No, I don't believe that. What we are interested in at this point is the semantic effect (or lack of it) of the potentially-removable join. It's fine to reason about that under the assumption that the joins will be done in syntactic order. If later parts of the planner decide to implement the joins in a different order, that cannot change the conclusion about whether it's safe to remove a join --- otherwise, either we were mistaken to remove the join, or the reordering logic is wrong. I prefer the code as it stands now because it helps to decouple the join-removal reasoning from the join-reordering logic, limiting any possible effect of bugs in the latter. (I think I might've had some other reason for changing it as well, but can't reconstruct that first thing in the morning.) regards, tom lane