pgsql: Fix duplicate enforcement of EC-derived conditions

From: Richard Guo <rguo(at)postgresql(dot)org>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Fix duplicate enforcement of EC-derived conditions
Date: 2026-09-10 01:04:21
Message-ID: E1x4TDA-00000004Csr-2s0R@gemulon.postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Fix duplicate enforcement of EC-derived conditions

A clause connecting the same two EC members can be requested from the
EC machinery in different contexts. When building parameterized index
paths for a relation, generate_implied_equalities_for_column derives
an indexable clause with parent_ec set, to mark it as redundant with
other join clauses derived from the same EC. Meanwhile, at a join
where the relations of a multi-relation EC member first come together,
generate_join_implied_equalities emits a clause equating the same two
members with parent_ec unset, since that clause is the sole enforcer
of its member there and must not be dropped as redundant. Because
create_join_clause treats parent_ec as part of its cache-lookup key,
such requests can yield two different RestrictInfos for the same
condition, carrying different rinfo_serials.

This breaks the assumption that one condition has exactly one serial
number, which create_nestloop_path relies on to drop join clauses that
are already enforced within a parameterized inner path. As a result,
the same condition could be enforced twice at different plan levels,
wasting execution effort and applying the clause's selectivity twice,
underestimating the join's row count.

To fix, make create_join_clause copy the rinfo_serial from an existing
clause that connects the same two members with the opposite parent_ec
marking, so that the two clauses keep their distinct markings but are
recognized as the same condition.

As a result, a duplicate join filter disappears from one of the
existing regression plans (the "cardinal_number" query in join.sql);
the other plan changes are join-order differences between plans of
essentially equal cost.

Author: Richard Guo <guofenglinux(at)gmail(dot)com>
Reviewed-by: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Discussion: https://postgr.es/m/CAMbWs4-3yZeBMGQDpmYRPdV-sL_=6H2AN=MoeneOT+VUk28PPg@mail.gmail.com
Backpatch-through: 19

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/895c1b5fe1ecaf3d0c5cb1ce5a85ab95e4c27dfb

Modified Files
--------------
src/backend/optimizer/path/equivclass.c | 15 ++++++++
src/test/regress/expected/join.out | 63 ++++++++++++++++++++++++++-------
src/test/regress/sql/join.sql | 24 +++++++++++++
3 files changed, 89 insertions(+), 13 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Michael Paquier 2026-09-10 02:04:08 pgsql: test_extensible: Improve handling of incorrect inputs
Previous Message Fujii Masao 2026-09-10 00:48:10 pgsql: postgres_fdw: Fix crash when estimating joins with functions