agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Fix duplicate enforcement of EC-derived conditions 2+ messages / 1 participants [nested] [flat]
* pgsql: Fix duplicate enforcement of EC-derived conditions @ 2026-09-10 01:04 Richard Guo <rguo@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Richard Guo @ 2026-09-10 01:04 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.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(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Fix duplicate enforcement of EC-derived conditions @ 2026-09-10 01:04 Richard Guo <rguo@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Richard Guo @ 2026-09-10 01:04 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.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(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-09-10 01:04 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-09-10 01:04 pgsql: Fix duplicate enforcement of EC-derived conditions Richard Guo <rguo@postgresql.org> 2026-09-10 01:04 pgsql: Fix duplicate enforcement of EC-derived conditions Richard Guo <rguo@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox