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 15:11:32 GMT
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