If it causes a regression in Drill then I think we should back it out. Especially as we have a week to stabilize the release.
Can you submit two commits, one backing out the fix to 783, and one adding the above query as a test case. I don't recall whether there is a jira case for the issue caused by the "fix" to 783, but it might make sense to create one. Julian On Thu, Aug 6, 2015 at 5:05 PM, Jinfeng Ni <[email protected]> wrote: > Hi Julian, > > Are we going to fix the bug introduced in CALCITE-783 [1] ( > https://issues.apache.org/jira/browse/CALCITE-783), regarding the collation > for LogicalAggregate? The code[2] is not right, by simply using input's > collation when construct a LogicalAggregate. > > This issue causes couple of regression test cases failure in Drill after we > re-base Drill on top of Calcite-1.4.0-SNAPSHOT, as LogicalAggregate does > not have valid collation. > > Also, this issue actually will cause the following query to hit CanNotPlan > exception in Calcite master branch (executed in Calcite sqlline): > > select sum(x), > count(distinct y) > from > ( > select > count(*) as x, > t1.JOB as y, > t1.DEPTNO as z > from > SCOTT.EMP t1 > group by t1.JOB, t1.DEPTNO > order by t1.JOB, t1.DEPTNO > ) sq(x,y,z) > group by z; > > Node [rel#37:Subset#7.ENUMERABLE.[]] could not be implemented; planner > state: > .... > > If I reverse the change of LogicalAggregate made in CALCITE-783, then the > query would run successful. > > I just want to know whether we are going to address this bug in release > 1.4.0, or the next release. > > Regards, > Jinfeng > > > [1] > https://github.com/apache/incubator-calcite/commit/c711fed6e2392f296554719a98b2d737da53c9b5 > [2] > https://github.com/apache/incubator-calcite/blob/master/core/src/main/java/org/apache/calcite/rel/logical/LogicalAggregate.java#L99-L111 > > > > On Sat, Aug 1, 2015 at 8:23 PM, Jacques Nadeau <[email protected]> wrote: > >> :D >> >> On Sat, Aug 1, 2015 at 7:02 PM, Julian Hyde <[email protected]> >> wrote: >> >> > Careful with making the database adhere to people’s “expectations". MySQL >> > used to guarantee that the output of GROUP BY is sorted and they lived to >> > regret it. >> > >> > > On Aug 1, 2015, at 8:58 AM, Jacques Nadeau <[email protected]> wrote: >> > > >> > > I think Aman and Vicki mentioned that this is a situation where most >> > > databases diverge from the spec since people have a certain >> expectation. >> > > >> > > On Fri, Jul 31, 2015 at 9:56 PM, Julian Hyde <[email protected]> wrote: >> > > >> > >> >> > >>> Jinfeng, the subquery's ORDER-BY can be dropped in some cases but not >> > >> all.. >> > >>> for instance in the following query: >> > >>> SELECT a1 FROM (SELECT a1 FROM t1 WHERE .... ORDER BY a1) LIMIT 10; >> > >>> The OB should not be dropped. There are other cases, this is one >> > >> example. >> > >> >> > >> FWIW, My understanding of the SQL standard is that that ORDER BY can >> be >> > >> dropped. You can’t rely on the order of output from a sub-query. If >> you >> > >> want the desired effect you have to combine ORDER BY and LIMIT into >> the >> > >> same clause. >> > >> >> > >> Julian >> > >> >> > >> >> > >> > >>
