calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jinfeng Ni <jinfengn...@gmail.com>
Subject Re: Collation meets relational algebra
Date Fri, 07 Aug 2015 17:01:56 GMT
Hi Julian,

I submitted pull request #118 for CALCITE-822, which contains two commits :
one from Milinda (use his authorship), and another one for the unit test
case.

https://github.com/apache/incubator-calcite/pull/118

Please review the pull request.



On Fri, Aug 7, 2015 at 8:11 AM, Jinfeng Ni <jinfengni99@gmail.com> wrote:

> Hi Julian,
>
> Since Milinda has already created CALCITE-822, and submitted a patch, it
> would makes sense to use his patch.
>
> I'll submit a separate patch to add the query as a test case.
>
>
>
> On Fri, Aug 7, 2015 at 7:23 AM, Milinda Pathirage <mpathira@umail.iu.edu>
> wrote:
>
>> Hi Julian,
>>
>> I created an issue [1] while ago and also attached a patch.
>>
>> Thanks
>> Milinda
>>
>> [1] https://issues.apache.org/jira/browse/CALCITE-822
>>
>> On Thu, Aug 6, 2015 at 9:21 PM, Julian Hyde <jhyde@apache.org> wrote:
>>
>> > 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 <jinfengni99@gmail.com>
>> 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 <jacques@apache.org>
>> > wrote:
>> > >
>> > >> :D
>> > >>
>> > >> On Sat, Aug 1, 2015 at 7:02 PM, Julian Hyde <jhyde.apache@gmail.com>
>> > >> 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 <jacques@apache.org>
>> > 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 <jhyde@apache.org>
>> > 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
>> > >> > >>
>> > >> > >>
>> > >> >
>> > >> >
>> > >>
>> >
>>
>>
>>
>> --
>> Milinda Pathirage
>>
>> PhD Student | Research Assistant
>> School of Informatics and Computing | Data to Insight Center
>> Indiana University
>>
>> twitter: milindalakmal
>> skype: milinda.pathirage
>> blog: http://milinda.pathirage.org
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message