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

diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index d92d43a17ea50385d04990d7b97fcf14d99e800e..0f423e9684728b0a24f9b78d06dcceb02d50e4b3 100644 (file)
--- 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;
 

diff --git a/src/test/regress/expected/groupingsets.out b/src/test/regress/expected/groupingsets.out
index 717383c4f3ad5d8c5648e82021a6af62d33a5a59..d7c9b44605d35c48adc784c5a7d52135dcd94b6d 100644 (file)
--- a/src/test/regress/expected/groupingsets.out
+++ b/src/test/regress/expected/groupingsets.out
@@ -860,6 +860,27 @@ explain (costs off)
                        ->  Seq Scan on gstest2
 (10 rows)
 
+-- test pushdown of HAVING clause that does not reference any columns that are nullable by grouping sets
+explain (costs off)
+select a, b, count(*) from gstest2 group by grouping sets ((a, b), (a)) having a > 1 and b > 1;
+           QUERY PLAN            
+---------------------------------
+ GroupAggregate
+   Group Key: a, b
+   Group Key: a
+   Filter: (b > 1)
+   ->  Sort
+         Sort Key: a, b
+         ->  Seq Scan on gstest2
+               Filter: (a > 1)
+(8 rows)
+
+select a, b, count(*) from gstest2 group by grouping sets ((a, b), (a)) having a > 1 and b > 1;
+ a | b | count 
+---+---+-------
+ 2 | 2 |     1
+(1 row)
+
 -- HAVING with GROUPING queries
 select ten, grouping(ten) from onek
 group by grouping sets(ten) having grouping(ten) >= 0

diff --git a/src/test/regress/sql/groupingsets.sql b/src/test/regress/sql/groupingsets.sql
index 660ca33efc14e99d82687e3e3e6d8d9c704cabf4..21cd31219406c91e1be18cacdf03584f430db183 100644 (file)
--- a/src/test/regress/sql/groupingsets.sql
+++ b/src/test/regress/sql/groupingsets.sql
@@ -279,6 +279,11 @@ explain (costs off)
   select v.c, (select count(*) from gstest2 group by () having v.c)
     from (values (false),(true)) v(c) order by v.c;
 
+-- test pushdown of HAVING clause that does not reference any columns that are nullable by grouping sets
+explain (costs off)
+select a, b, count(*) from gstest2 group by grouping sets ((a, b), (a)) having a > 1 and b > 1;
+select a, b, count(*) from gstest2 group by grouping sets ((a, b), (a)) having a > 1 and b > 1;
+
 -- HAVING with GROUPING queries
 select ten, grouping(ten) from onek
 group by grouping sets(ten) having grouping(ten) >= 0