drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Camuel Gilyadov <cam...@gmail.com>
Subject Re: DrQL grammar and parser
Date Tue, 28 Aug 2012 15:57:23 GMT
So different view boils down to feasibility and utility of a logical query
plan. I think we have elaborated the issue by now and as next action item I
would suggest those eager to support the idea to come up and publish here
the draft of such a query plan. I promise to provide constructive critique
:) and would love to see myself being wrong here

I now working on the OpenDremel codebase, preparing it to be considered as
initial code commit to Apache Drill. Let me know if anyone is interested to
get involved right now...




On Tue, Aug 28, 2012 at 6:26 PM, Ted Dunning <ted.dunning@gmail.com> wrote:

> On Tue, Aug 28, 2012 at 8:03 AM, Camuel Gilyadov <camuel@gmail.com> wrote:
>
> > I think different views are essential for a fruitful brainstorming :)
> >
>
> Sounds right.
>
>
> > However, I never suggested optimizing AST and bypassing query-plan
> > abstraction altogether. I was suggesting:
> >
> > 1. Not formalizing query plan, especially not upfront formalizing it.
> >
>
> Hmm... this is not a good limitation in my view, but I do think that
> flexibility is probably a good idea here.
>
>
> > 2. Not calling query plan - logical query plan.
> >
>
> This is a naming question which I don't much care about.
>
>
> > 3. Not making query plan a stable abstraction/interface of the back-end
> and
> > then having multiple front-end generating it.
> >
>
> I think we differ here.  This style has proven very useful in the past for
> other problems (think Java).  Not having such a thing has made Pig and Hive
> much less rich.
>
>
> > 4. Heavily downplaying query-optimization in Dremel as not even remotely
> as
> > important as with traditional DBMS.
> >
>
> This is clearly true.  Dremel is, as others have said, all about doing
> single pass filtering very nicely.  Drill will likely be somewhat similar.
>
> The main optimizations to be had are about push-downs and data source
> specific scan optimizations.  For these, I think it is important to have a
> clean and simple structure for communicating these things.
>
> 5. To consider making DrQL - main language of the Drill in which everything
> > Drill is capable of - could be expressed and then having other frontends
> > generating directly DrQL. For this DrQL must be extended. Added benefit
> > would be that user would have access to it also.
> >
>
> Being a big fan of Pig-style query writing, as well as a fan of FlumeJava,
> I would not like this policy statement.
>
>
> > 6. To consider making backend as generic as possible so for more
> innovative
> > frontends it would be possible to bypass main frontend and talk directly
> to
> > backend.
> >
>
> This seems like a great idea.  To me, this is facilitated by having a nice
> way to talk to the backend ... which sounds like a logical query form.
>

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