On Mon, Apr 20, 2026 at 11:32 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Richard Guo <guofenglinux@gmail.com> writes:
> > On Mon, Apr 20, 2026 at 10:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> 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.
> > The reason seems to be that the equality constraint is a restriction
> > clause for the inner relation 't', and is needed to determine that the
> > relation has a matching unique index and is therefore distinct. If we
> > remove it, or change it to something that isn't mergejoinable, we
> > won't be able to prove the inner side of the left join is distinct,
> > and thus won't be able to remove that left join.
> Hmm. The bug also goes away if "t" doesn't have a unique/pkey
> constraint, and I find that easy to understand: we can't apply outer
> join removal unless rel_supports_distinctness/rel_is_distinct_for
> succeed, so that this buggy code in remove_rel_from_restrictinfo
> is not reached. But that logic doesn't consider WHERE constraints
> AFAICS. So I think there is some other code path involved.
Hmm, relation_has_unique_index_for does consider the lower "WHERE t.id
= ..." clause, as that clause is a restriction clause for "t", and
relation_has_unique_index_for automatically adds any usable
restriction clauses for the rel.
- Richard
