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.96) (envelope-from ) id 1wEdQ7-004EQO-1n for pgsql-bugs@arkaria.postgresql.org; Mon, 20 Apr 2026 01:27:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wEdP7-0002Vo-28 for pgsql-bugs@arkaria.postgresql.org; Mon, 20 Apr 2026 01:26:25 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wEdP7-0002VY-1J for pgsql-bugs@lists.postgresql.org; Mon, 20 Apr 2026 01:26:25 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wEdP5-00000001qhQ-0cdG for pgsql-bugs@lists.postgresql.org; Mon, 20 Apr 2026 01:26:24 +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 63K1QEMi081858; Sun, 19 Apr 2026 21:26:14 -0400 From: Tom Lane To: Richard Guo cc: francois.jehl@pigment.com, pgsql-bugs@lists.postgresql.org, Robert Haas Subject: Re: BUG #19460: FULL JOIN rewriting issue on empty queries In-reply-to: References: <19460-5625143cef66012f@postgresql.org> <53936.1776633020@sss.pgh.pa.us> Comments: In-reply-to Richard Guo message dated "Mon, 20 Apr 2026 10:12:11 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <81856.1776648374.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Sun, 19 Apr 2026 21:26:14 -0400 Message-ID: <81857.1776648374@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > On Mon, Apr 20, 2026 at 6:10 AM Tom Lane wrote: >> This turns out to be because somebody long ago thought that outer join >> removal could be lazy about how much of the planner's data structures >> it needs to update. Specifically, when the lower LEFT OUTER JOIN >> gets removed, we failed to remove the associated relids from the >> left_relids and right_relids of the upper "ON rhs.id = lhs.id" clause, >> and that blocks recognition of the applicability of a hash or merge >> join, because clause_sides_match_join() fails. > I came to the same conclusion. Thanks for looking at it! There is a loose end still bothering me: if you remove the lower "WHERE t.id = ..." clause, or change it to be something other than an equality constraint on t.id, the bug doesn't manifest. The reason for that is un-obvious. I suppose it's somehow related to the code that tries to push equality-to-a-constant through outer join clauses, but that code shouldn't be able to produce any new clauses here, so why is there a visible effect? I'm too tired to look right now, and was planning to study it more tomorrow. But if you are interested in digging before that, feel free. regards, tom lane