drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: DrQL grammar and parser
Date Tue, 28 Aug 2012 15:26:49 GMT
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