drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Camuel Gilyadov <cam...@gmail.com>
Subject Re: next steps
Date Sun, 14 Oct 2012 15:37:30 GMT
On Thu, Oct 11, 2012 at 12:59 AM, Ted Dunning <ted.dunning@gmail.com> wrote:

> I would like to shepherd the web front end, the query parser and some
> documentation into the project next.
> Michael,
> You have the web front end ready it sounds like.  Can you provide us a
> walk-through?
> Camuel,
> You and your team have the parser in some kind of shape.  We still need to
> discuss and settle on an intermediate language to pass to the query
> optimizer and source code organization.  Also, how does the syntax below
> look to you as a target?

As I have written previously, parser will note emit any logical plan but
will provide AST iteration kind of interface and this is pretty much
already working.

The next step is to write a parser for schema and we started with .proto
files but then it seems to me that it is not yet a consensus there here in
what language we describe schema and a very adjacent question which
serialization format we are going to use.

I'll start a new thread discussing schema language and serialization
format. This will allow us complete the parser and start semantic analyzer
(which would validate and annotate the query) and only then there will be
an option for logical plan generation or strait-forward compilation to LLVM

> Julian H,
> Can you comment on what you would like to see as a logical plan syntax?  My
> thought was to describe the logical plan as virtual assignments in a style
> similar to (but very distinct from) LLVM.  The syntax would look something
> like this:
>    dest := op arg1, arg2, ... argN
> op would be one of a small list of operators.  Arg's would be destinations
> from earlier in the file.  Even arithmetic expressions and built-in
> functions would be in this form.
> Would this look OK to you?
> If so, what list of op's should we target first?

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