diff --git a/src/backend/optimizer/plan/analyzejoins.c b/src/backend/optimizer/plan/analyzejoins.c index 129fc3d..1cdb311 100644 --- a/src/backend/optimizer/plan/analyzejoins.c +++ b/src/backend/optimizer/plan/analyzejoins.c @@ -27,9 +27,15 @@ #include "optimizer/paths.h" #include "optimizer/planmain.h" #include "optimizer/var.h" +#include "optimizer/clauses.h" +#include "parser/parsetree.h" +#include "optimizer/tlist.h" +#include "nodes/nodeFuncs.h" /* local functions */ static bool join_is_removable(PlannerInfo *root, SpecialJoinInfo *sjinfo); +static bool groupinglist_is_unique_on_restrictinfo(Query *query, + List *clause_list, List *sortlist); static void remove_rel_from_query(PlannerInfo *root, int relid, Relids joinrelids); static List *remove_rel_from_joinlist(List *joinlist, int relid, int *nremoved); @@ -147,19 +153,33 @@ join_is_removable(PlannerInfo *root, SpecialJoinInfo *sjinfo) { int innerrelid; RelOptInfo *innerrel; + Query *subquery; Relids joinrelids; List *clause_list = NIL; ListCell *l; int attroff; /* - * Currently, we only know how to remove left joins to a baserel with - * unique indexes. We can check most of these criteria pretty trivially - * to avoid doing useless extra work. But checking whether any of the - * indexes are unique would require iterating over the indexlist, so for - * now we just make sure there are indexes of some sort or other. If none - * of them are unique, join removal will still fail, just slightly later. + * Assuming none of the variables from the join are needed by the query, + * it is possible here to remove a left join providing we can determine + * that the join will never produce more than 1 row that matches the join + * condition. + * + * There are a few ways that we can do this: + * + * 1. When joining to a baserel we can check if a unique index exists + * where all of the columns of the index are seen in the join condition + * with equality operators. + * + * 2. When joining to a subquery we can check if the subquery contains a + * GROUP BY or DISTINCT clause where all of the columns of the clause + * appear in the join condition with equality operators. + * + * The code below is written with the assumption that join removal is more + * likely not to happen, for this reason there are fast paths for both of + * the cases above to try to save on unnecessary processing. */ + if (sjinfo->jointype != JOIN_LEFT || sjinfo->delay_upper_joins || bms_membership(sjinfo->min_righthand) != BMS_SINGLETON) @@ -168,11 +188,34 @@ join_is_removable(PlannerInfo *root, SpecialJoinInfo *sjinfo) innerrelid = bms_singleton_member(sjinfo->min_righthand); innerrel = find_base_rel(root, innerrelid); - if (innerrel->reloptkind != RELOPT_BASEREL || - innerrel->rtekind != RTE_RELATION || - innerrel->indexlist == NIL) + if (innerrel->reloptkind != RELOPT_BASEREL) return false; + if (innerrel->rtekind == RTE_RELATION) + { + /* + * If there are no indexes then there's certainly no unique indexes + * so there's no need to go any further. + */ + if (innerrel->indexlist == NIL) + return false; + } + else if (innerrel->rtekind == RTE_SUBQUERY) + { + subquery = root->simple_rte_array[innerrelid]->subquery; + + /* + * The only means we currently use to check if the subquery is unique + * are the GROUP BY and DISTINCT clause. If both of these are empty + * then there's no point in going any further. + */ + if (subquery->groupClause == NIL && + subquery->distinctClause == NIL) + return false; + } + else + return false; /* unsupported rtekind */ + /* Compute the relid set for the join we are considering */ joinrelids = bms_union(sjinfo->min_lefthand, sjinfo->min_righthand); @@ -276,16 +319,140 @@ join_is_removable(PlannerInfo *root, SpecialJoinInfo *sjinfo) */ /* Now examine the indexes to see if we have a matching unique index */ - if (relation_has_unique_index_for(root, innerrel, clause_list, NIL, NIL)) + if (innerrel->rtekind == RTE_RELATION && + relation_has_unique_index_for(root, innerrel, clause_list, NIL, NIL)) return true; /* + * We can be certain that the sub query contains no duplicate values for + * the join clause if item in the sub query's GROUP BY clause is also used + * in the join clause using equality. This works the same way for the + * DISTINCT clause. We need not pay any attention to WHERE or HAVING + * clauses as these just restrict the results more and could not be the + * cause of duplication in the result set. However there are a number of + * pre-checks we must perform which could cause duplicate values even if + * all the required columns are in the GROUP BY or DISTINCT clause. + * + * NB: We must also not remove the join in the subquery contains a + * FOR UDPATE clause, but we can actually skip this check as GROUP BY and + * DISTINCT cannot be used at the same time as FOR UPDATE. + */ + if (innerrel->rtekind == RTE_SUBQUERY) + { + Assert(subquery == root->simple_rte_array[innerrelid]->subquery); + + /* + * We cannot remove the subquery if the target list contains any set + * returning functions as these may cause the query not to be unique + * on the grouping columns, as per the following example: + * "SELECT a.a,generate_series(1,2) FROM (VALUES(1)) a(a) GROUP BY a" + */ + if (expression_returns_set((Node *) subquery->targetList)) + return false; + + /* + * Don't remove the join if the target list contains any volatile + * functions. Doing so may remove desired side affects that calls + * to the function may cause. + */ + if (contain_volatile_functions((Node *) subquery->targetList)) + return false; + + /* + * It should be safe to remove the join if all the GROUP BY expressions + * have matching items in the join condition. + */ + if (subquery->groupClause != NIL && + groupinglist_is_unique_on_restrictinfo(subquery, clause_list, subquery->groupClause)) + return true; + + /* + * It should be safe to remove the join if all the DISTINCT column list have matching + * items in the join condition. + */ + if (subquery->distinctClause != NIL && + groupinglist_is_unique_on_restrictinfo(subquery, clause_list, subquery->distinctClause)) + return true; + } + + /* * Some day it would be nice to check for other methods of establishing * distinctness. */ return false; } +/* + * groupinglist_is_unique_on_restrictinfo + * + * Checks to see if all items in groupinglist also exist in rinfolist. + * The function will return true if rinfolist is the same as or a superset + * of groupinglist. If the groupinglist has Vars that don't exist in the rinfolist + * then the query can't be guaranteed unique on the rinfolist columns. + * + * Note: The calling function must ensure that groupinglist is not NIL. + */ +static bool +groupinglist_is_unique_on_restrictinfo(Query *query, List *rinfolist, List *groupinglist) +{ + ListCell *l; + + Assert(groupinglist != NIL); + + /* + * Loop over each groupinglist item to ensure that we have restrictinfo + * item to match. We also need to ensure that the operators used in the + * groupinglist matches that of the one in the restrict info. + * Note that it does not matter if we have more items in the rinfolist than + * we have in the groupinglist. + */ + foreach(l, groupinglist) + { + ListCell *ri; + SortGroupClause *scl = (SortGroupClause *) lfirst(l); + TargetEntry *sortTarget; + bool matched = false; + + /* lookup the target list entry for the current sort sort group ref */ + sortTarget = get_sortgroupref_tle(scl->tleSortGroupRef, query->targetList); + + /* + * We can ignore constants since they have only one value and don't + * affect uniqueness of results. + */ + if (IsA(sortTarget->expr, Const)) + continue; + + foreach(ri, rinfolist) + { + RestrictInfo *rinfo = (RestrictInfo *) lfirst(ri); + Node *rexpr; + + if (rinfo->outer_is_left) + rexpr = get_rightop(rinfo->clause); + else + rexpr = get_leftop(rinfo->clause); + + if (IsA(rexpr, Var)) + { + Var *var = (Var *)rexpr; + + if (var->varattno == sortTarget->resno && + scl->eqop == rinfo->hashjoinoperator) + { + matched = true; + break; /* match found */ + } + } + else + return false; + } + + if (!matched) + return false; + } + return true; +} /* * Remove the target relid from the planner's data structures, having diff --git a/src/test/regress/expected/join.out b/src/test/regress/expected/join.out index c62a63f..4959e5f 100644 --- a/src/test/regress/expected/join.out +++ b/src/test/regress/expected/join.out @@ -3131,9 +3131,11 @@ begin; CREATE TEMP TABLE a (id int PRIMARY KEY, b_id int); CREATE TEMP TABLE b (id int PRIMARY KEY, c_id int); CREATE TEMP TABLE c (id int PRIMARY KEY); +CREATE TEMP TABLE d (a INT, b INT); INSERT INTO a VALUES (0, 0), (1, NULL); INSERT INTO b VALUES (0, 0), (1, NULL); INSERT INTO c VALUES (0), (1); +INSERT INTO d VALUES (1,3),(2,2),(3,1); -- all three cases should be optimizable into a simple seqscan explain (costs off) SELECT a.* FROM a LEFT JOIN b ON a.b_id = b.id; QUERY PLAN @@ -3169,6 +3171,161 @@ select id from a where id in ( -> Seq Scan on b (5 rows) +-- check that join removal works for a left join when joining a subquery +-- that is guaranteed to be unique on the join condition by the GROUP BY clause +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT b.id FROM b GROUP BY b.id) b ON a.b_id = b.id; + QUERY PLAN +--------------- + Seq Scan on a +(1 row) + +-- check that join removal works for a left join when joining a subquery +-- that is guaranteed to be unique on the join condition by the GROUP BY clause +-- which contains more than 1 column. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT b.id,b.c_id FROM b GROUP BY b.id,b.c_id) b ON a.b_id = b.id AND a.id = b.c_id; + QUERY PLAN +--------------- + Seq Scan on a +(1 row) + +-- check that join removal works for a left join when joining a subquery +-- where the join condition is a superset of the columns in the GROUP BY. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a +LEFT JOIN (SELECT b.id,c_id FROM b GROUP BY b.id) b ON a.id = b.id AND b.c_id = 1; + QUERY PLAN +--------------- + Seq Scan on a +(1 row) + +-- check that join removal works for a left join when joining a subquery +-- that is guaranteed to be unique on the join condition by the DISTINCT clause +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT DISTINCT a+b AS ab FROM d) d ON a.id = d.ab; + QUERY PLAN +--------------- + Seq Scan on a +(1 row) + +-- join removal is not possible when distinct contains a volatile function +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT DISTINCT a+b+random() AS abr FROM d) d ON a.id = d.abr; + QUERY PLAN +------------------------------------------------------------------------------------------ + Hash Left Join + Hash Cond: ((a.id)::double precision = ((((d.a + d.b))::double precision + random()))) + -> Seq Scan on a + -> Hash + -> HashAggregate + Group Key: (((d.a + d.b))::double precision + random()) + -> Seq Scan on d +(7 rows) + +-- check that join removal works for a left join when joining a subquery that +-- is guaranteed to be unique on the join condition even if it contains a Const. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT DISTINCT b.c_id,1 AS dummy FROM b) b ON a.id = b.c_id; + QUERY PLAN +--------------- + Seq Scan on a +(1 row) + +-- check join removal works when joining to a subquery that is guaranteed to be +-- unique on the join condition even when the subquery itself involves a join. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT b.id FROM b INNER JOIN c ON b.id = c.id GROUP BY b.id) b ON a.id + 10 = b.id; + QUERY PLAN +--------------- + Seq Scan on a +(1 row) + +-- check join removal works with a left join when joining a unique subquery which +-- contains 2 tables where the uniqueness enforced by the GROUP BY clause is a +-- subset of the join condition. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a +LEFT JOIN (SELECT b.id,1 as dummy FROM b INNER JOIN c ON b.id = c.id GROUP BY b.id) b ON a.id = b.id AND b.dummy = 1; + QUERY PLAN +--------------- + Seq Scan on a +(1 row) + +-- join removal is not possible when the GROUP BY contains a column which is +-- not in the join condition. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT b.id FROM b GROUP BY b.id,b.c_id) b ON a.id = b.id; + QUERY PLAN +--------------------------------- + Hash Right Join + Hash Cond: (b.id = a.id) + -> HashAggregate + Group Key: b.id, b.c_id + -> Seq Scan on b + -> Hash + -> Seq Scan on a +(7 rows) + +-- join removal is not possible when DISTINCT clause contains a column which is +-- not in the join condition. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT DISTINCT b.id,c_id FROM b) b ON a.id = b.id; + QUERY PLAN +--------------------------------- + Hash Right Join + Hash Cond: (b.id = a.id) + -> HashAggregate + Group Key: b.id, b.c_id + -> Seq Scan on b + -> Hash + -> Seq Scan on a +(7 rows) + +-- join removal is not possible when DISTINCT contains a volatile function +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT DISTINCT b.id,random() AS r FROM b) b ON a.id = b.id AND r = random(); + QUERY PLAN +------------------------------------------------- + Hash Left Join + Hash Cond: (a.id = b.id) + -> Seq Scan on a + -> Hash + -> Subquery Scan on b + Filter: (b.r = random()) + -> HashAggregate + Group Key: b_1.id, random() + -> Seq Scan on b b_1 +(9 rows) + +-- join removal is not possible when there are any volatile functions in the target list. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT id,AVG(c_id),SUM(random()) FROM b GROUP BY id) b ON a.id = b.id; + QUERY PLAN +---------------------------- + Hash Right Join + Hash Cond: (b.id = a.id) + -> HashAggregate + Group Key: b.id + -> Seq Scan on b + -> Hash + -> Seq Scan on a +(7 rows) + +-- join removal is not possible when there are set returning functions in the target list. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT id,generate_series(1,2) FROM b GROUP BY id) b ON a.id = b.id; + QUERY PLAN +---------------------------- + Hash Right Join + Hash Cond: (b.id = a.id) + -> HashAggregate + Group Key: b.id + -> Seq Scan on b + -> Hash + -> Seq Scan on a +(7 rows) + rollback; create temp table parent (k int primary key, pd int); create temp table child (k int unique, cd int); diff --git a/src/test/regress/sql/join.sql b/src/test/regress/sql/join.sql index 1031f26..21e29d2 100644 --- a/src/test/regress/sql/join.sql +++ b/src/test/regress/sql/join.sql @@ -919,9 +919,11 @@ begin; CREATE TEMP TABLE a (id int PRIMARY KEY, b_id int); CREATE TEMP TABLE b (id int PRIMARY KEY, c_id int); CREATE TEMP TABLE c (id int PRIMARY KEY); +CREATE TEMP TABLE d (a INT, b INT); INSERT INTO a VALUES (0, 0), (1, NULL); INSERT INTO b VALUES (0, 0), (1, NULL); INSERT INTO c VALUES (0), (1); +INSERT INTO d VALUES (1,3),(2,2),(3,1); -- all three cases should be optimizable into a simple seqscan explain (costs off) SELECT a.* FROM a LEFT JOIN b ON a.b_id = b.id; @@ -936,6 +938,71 @@ select id from a where id in ( select b.id from b left join c on b.id = c.id ); +-- check that join removal works for a left join when joining a subquery +-- that is guaranteed to be unique on the join condition by the GROUP BY clause +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT b.id FROM b GROUP BY b.id) b ON a.b_id = b.id; + +-- check that join removal works for a left join when joining a subquery +-- that is guaranteed to be unique on the join condition by the GROUP BY clause +-- which contains more than 1 column. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT b.id,b.c_id FROM b GROUP BY b.id,b.c_id) b ON a.b_id = b.id AND a.id = b.c_id; + +-- check that join removal works for a left join when joining a subquery +-- where the join condition is a superset of the columns in the GROUP BY. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a +LEFT JOIN (SELECT b.id,c_id FROM b GROUP BY b.id) b ON a.id = b.id AND b.c_id = 1; + +-- check that join removal works for a left join when joining a subquery +-- that is guaranteed to be unique on the join condition by the DISTINCT clause +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT DISTINCT a+b AS ab FROM d) d ON a.id = d.ab; + +-- join removal is not possible when distinct contains a volatile function +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT DISTINCT a+b+random() AS abr FROM d) d ON a.id = d.abr; + +-- check that join removal works for a left join when joining a subquery that +-- is guaranteed to be unique on the join condition even if it contains a Const. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT DISTINCT b.c_id,1 AS dummy FROM b) b ON a.id = b.c_id; + +-- check join removal works when joining to a subquery that is guaranteed to be +-- unique on the join condition even when the subquery itself involves a join. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT b.id FROM b INNER JOIN c ON b.id = c.id GROUP BY b.id) b ON a.id + 10 = b.id; + +-- check join removal works with a left join when joining a unique subquery which +-- contains 2 tables where the uniqueness enforced by the GROUP BY clause is a +-- subset of the join condition. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a +LEFT JOIN (SELECT b.id,1 as dummy FROM b INNER JOIN c ON b.id = c.id GROUP BY b.id) b ON a.id = b.id AND b.dummy = 1; + +-- join removal is not possible when the GROUP BY contains a column which is +-- not in the join condition. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT b.id FROM b GROUP BY b.id,b.c_id) b ON a.id = b.id; + +-- join removal is not possible when DISTINCT clause contains a column which is +-- not in the join condition. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT DISTINCT b.id,c_id FROM b) b ON a.id = b.id; + +-- join removal is not possible when DISTINCT contains a volatile function +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT DISTINCT b.id,random() AS r FROM b) b ON a.id = b.id AND r = random(); + +-- join removal is not possible when there are any volatile functions in the target list. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT id,AVG(c_id),SUM(random()) FROM b GROUP BY id) b ON a.id = b.id; + +-- join removal is not possible when there are set returning functions in the target list. +EXPLAIN (COSTS OFF) +SELECT a.id FROM a LEFT JOIN (SELECT id,generate_series(1,2) FROM b GROUP BY id) b ON a.id = b.id; + rollback; create temp table parent (k int primary key, pd int);