diff options
author | Richard Guo <rguo@postgresql.org> | 2024-10-09 17:19:04 +0900 |
---|---|---|
committer | Richard Guo <rguo@postgresql.org> | 2024-10-09 17:19:04 +0900 |
commit | 67a54b9e83d331eadd3a595e6c3bfec06288d2c4 (patch) | |
tree | 98bde85da279ae7a3f0441323e32d00eb8f46697 /src/backend/optimizer/plan/planner.c | |
parent | 828e94c9d2fd87c06a75354361543119d9937068 (diff) | |
download | postgresql-67a54b9e83d331eadd3a595e6c3bfec06288d2c4.tar.gz postgresql-67a54b9e83d331eadd3a595e6c3bfec06288d2c4.zip |
Allow pushdown of HAVING clauses with grouping sets
In some cases, we may want to transfer a HAVING clause into WHERE in
hopes of eliminating tuples before aggregation instead of after.
Previously, we couldn't do this if there were any nonempty grouping
sets, because we didn't have a way to tell if the HAVING clause
referenced any columns that were nullable by the grouping sets, and
moving such a clause into WHERE could potentially change the results.
Now, with expressions marked nullable by grouping sets with the RT
index of the RTE_GROUP RTE, it is much easier to identify those
clauses that reference any nullable-by-grouping-sets columns: we just
need to check if the RT index of the RTE_GROUP RTE is present in the
clause. For other HAVING clauses, they can be safely pushed down.
Author: Richard Guo
Discussion: https://postgr.es/m/CAMbWs4-NpzPgtKU=hgnvyn+J-GanxQCjrUi7piNzZ=upiCV=2Q@mail.gmail.com
Diffstat (limited to 'src/backend/optimizer/plan/planner.c')
-rw-r--r-- | src/backend/optimizer/plan/planner.c | 17 |
1 files changed, 9 insertions, 8 deletions
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c index d92d43a17ea..0f423e96847 100644 --- a/src/backend/optimizer/plan/planner.c +++ b/src/backend/optimizer/plan/planner.c @@ -1047,10 +1047,10 @@ subquery_planner(PlannerGlobal *glob, Query *parse, PlannerInfo *parent_root, * cannot do so if the HAVING clause contains aggregates (obviously) or * volatile functions (since a HAVING clause is supposed to be executed * only once per group). We also can't do this if there are any nonempty - * grouping sets; moving such a clause into WHERE would potentially change - * the results, if any referenced column isn't present in all the grouping - * sets. (If there are only empty grouping sets, then the HAVING clause - * must be degenerate as discussed below.) + * grouping sets and the clause references any columns that are nullable + * by the grouping sets; moving such a clause into WHERE would potentially + * change the results. (If there are only empty grouping sets, then the + * HAVING clause must be degenerate as discussed below.) * * Also, it may be that the clause is so expensive to execute that we're * better off doing it only once per group, despite the loss of @@ -1088,15 +1088,16 @@ subquery_planner(PlannerGlobal *glob, Query *parse, PlannerInfo *parent_root, { Node *havingclause = (Node *) lfirst(l); - if ((parse->groupClause && parse->groupingSets) || - contain_agg_clause(havingclause) || + if (contain_agg_clause(havingclause) || contain_volatile_functions(havingclause) || - contain_subplans(havingclause)) + contain_subplans(havingclause) || + (parse->groupClause && parse->groupingSets && + bms_is_member(root->group_rtindex, pull_varnos(root, havingclause)))) { /* keep it in HAVING */ newHaving = lappend(newHaving, havingclause); } - else if (parse->groupClause && !parse->groupingSets) + else if (parse->groupClause) { Node *whereclause; |