| 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-00000004Csw-32Ro@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
------
REL_19_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/7c620d2bf87bdb9508dd8cb40377f84388244dca
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(-)
| 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 |