diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2023-01-30 13:50:25 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2023-01-30 13:50:25 -0500 |
| commit | 3bef56e11650a33f70adeb6dd442bc2b48bb9b72 (patch) | |
| tree | 5a817197ed4f7b1f54abc7349dfab3f17bb946c8 /src/backend/optimizer/path/joinpath.c | |
| parent | b448f1c8d83f8b65e2f0080c556ee21a7076da25 (diff) | |
| download | postgresql-3bef56e11650a33f70adeb6dd442bc2b48bb9b72.tar.gz postgresql-3bef56e11650a33f70adeb6dd442bc2b48bb9b72.zip | |
Invent "join domains" to replace the below_outer_join hack.
EquivalenceClasses are now understood as applying within a "join
domain", which is a set of inner-joined relations (possibly underneath
an outer join). We no longer need to treat an EC from below an outer
join as a second-class citizen.
I have hopes of eventually being able to treat outer-join clauses via
EquivalenceClasses, by means of only applying deductions within the
EC's join domain. There are still problems in the way of that, though,
so for now the reconsider_outer_join_clause logic is still here.
I haven't been able to get rid of RestrictInfo.is_pushed_down either,
but I wonder if that could be recast using JoinDomains.
I had to hack one test case in postgres_fdw.sql to make it still test
what it was meant to, because postgres_fdw is inconsistent about
how it deals with quals containing non-shippable expressions; see
https://postgr.es/m/1691374.1671659838@sss.pgh.pa.us. That should
be improved, but I don't think it's within the scope of this patch
series.
Patch by me; thanks to Richard Guo for review.
Discussion: https://postgr.es/m/830269.1656693747@sss.pgh.pa.us
Diffstat (limited to 'src/backend/optimizer/path/joinpath.c')
| -rw-r--r-- | src/backend/optimizer/path/joinpath.c | 12 |
1 files changed, 0 insertions, 12 deletions
diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c index dfbb839be16..9d4a9197ee6 100644 --- a/src/backend/optimizer/path/joinpath.c +++ b/src/backend/optimizer/path/joinpath.c @@ -2334,18 +2334,6 @@ select_mergejoin_clauses(PlannerInfo *root, * canonical pathkey list, but redundant eclasses can't appear in * canonical sort orderings. (XXX it might be worth relaxing this, * but not enough time to address it for 8.3.) - * - * Note: it would be bad if this condition failed for an otherwise - * mergejoinable FULL JOIN clause, since that would result in - * undesirable planner failure. I believe that is not possible - * however; a variable involved in a full join could only appear in - * below_outer_join eclasses, which aren't considered redundant. - * - * This case *can* happen for left/right join clauses: the outer-side - * variable could be equated to a constant. Because we will propagate - * that constant across the join clause, the loss of ability to do a - * mergejoin is not really all that big a deal, and so it's not clear - * that improving this is important. */ update_mergeclause_eclasses(root, restrictinfo); |