postgres.git / summary / log / commit / refs

commit    61444bfb809d3a088a270a59f383af3d4cd157b0
Author:   Andres Freund <andres@anarazel.de>
Date:     Sun Jul 26 13:56:26 2015 +0000

    Allow to push down clauses from HAVING to WHERE when grouping sets are used.
    
    Previously we disallowed pushing down quals to WHERE in the presence of
    grouping sets. That's overly restrictive.
    
    We now instead copy quals to WHERE if applicable, leaving the
    one in HAVING in place. That's because, at that stage of the planning
    process, it's nontrivial to determine if it's safe to remove the one in
    HAVING.
    
    Author: Andrew Gierth
    Discussion: 874mkt3l59.fsf@news-spur.riddles.org.uk
    Backpatch: 9.5, where grouping sets were introduced. This isn't exactly
        a bugfix, but it seems better to keep the branches in sync at this point.


 src/backend/optimizer/plan/planner.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 11678388fab..6ee411eec87 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -570,13 +570,12 @@ subquery_planner(PlannerGlobal *glob, Query *parse,
 
 		if (contain_agg_clause(havingclause) ||
 			contain_volatile_functions(havingclause) ||
-			contain_subplans(havingclause) ||
-			parse->groupingSets)
+			contain_subplans(havingclause))
 		{
 			/* keep it in HAVING */
 			newHaving = lappend(newHaving, havingclause);
 		}
-		else if (parse->groupClause)
+		else if (parse->groupClause && !parse->groupingSets)
 		{
 			/* move it to WHERE */
 			parse->jointree->quals = (Node *)


[parent: e6d8cb77c029]