Re: BUG #19460: FULL JOIN rewriting issue on empty queries
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: francois.jehl@pigment.com, pgsql-bugs@lists.postgresql.org,
Robert Haas <robertmhaas@gmail.com>
Date: 2026-04-20T01:26:14Z
Lists: pgsql-bugs
Richard Guo <guofenglinux@gmail.com> writes: > On Mon, Apr 20, 2026 at 6:10 AM Tom Lane <tgl@sss.pgh.pa.us> 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
Commits
-
Fix relid-set clobber during join removal.
- f0ac6d494b56 19 (unreleased) landed
- 798dabe83887 16.14 landed
- 53cb4ec1ded7 17.10 landed
-
Clean up all relid fields of RestrictInfos during join removal.
- d509be4ace90 16.14 landed
- cfcd5711160a 19 (unreleased) landed
- 766d40286600 17.10 landed
- 16fb94605c8f 18.4 landed