On Tue, Jul 14, 2015 at 4:23 PM, Andrew Gierth <and...@tao11.riddles.org.uk> wrote:
> >>>>> "Jeevan" == Jeevan Chalke <jeevan.cha...@enterprisedb.com> writes: > > Jeevan> Basically, when we have only one element in GROUING SETS, we > Jeevan> are assuming it as a simple GROUP BY with one column. Due to > Jeevan> which we are ending up with this error. > > Jeevan> If we have ROLLUP/CUBE or GROUPING SETS with multiple elements, > Jeevan> then we are not getting this error. > > There's two issues here. One you correctly identified, which is that > contain_agg_clause() should be true for GroupingFuncs too. > > The other is that in subquery_planner, the optimization of converting > HAVING clauses to WHERE clauses is suppressed if parse->groupingSets > isn't empty. (It is empty if there's either no group by clause at all, > or if there's exactly one grouping set, which must not be empty, however > derived.) This is costing us some optimizations, especially in the case > of an explicit GROUP BY () clause; I have observed that. But I thought that it is indeed intentional. As we don't want to choose code path for GSets when we have only one column which is converted to plain group by and thus setting parse->groupingSets to FALSE. > I'll look into this. > OK. Thanks > In the meantime your patch looks OK (and necessary) to me. > > Jeevan> The side effect is that, if we have plain group by clause, then > Jeevan> too we can use GROUPING in HAVING clause. But I guess it is > Jeevan> fine. > > GROUPING is, per spec, explicitly allowed anywhere you could have an > aggregate call, whether the group by clause is plain or not. > > -- > Andrew (irc:RhodiumToad) > -- Jeevan B Chalke Principal Software Engineer, Product Development EnterpriseDB Corporation The Enterprise PostgreSQL Company
