drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Nadeau <jacques.dr...@gmail.com>
Subject Re: Expressions in the Logical Plan
Date Sat, 17 Nov 2012 21:13:36 GMT
Let me give an answer that may help understanding.  The logical plan tries
to be as generic as possible.  As such, all types are basic types.  That
being said, we'll surely have a large selection of various types of
functions which could modify a value.  For example currency(integer) might
convert a number of pennies into a dollar amount 3500 > "$35.00".  The
query layer will be responsible for converting the particular query
language to a set of these various functions.  Then the optimizer decides
where to apply those functions.  Lastly, the execution layer runs them as
efficiently as possible givens it execution environment.  Given all of
this, it is highly likely (especially early on) that a new parser may also
introduce new functions that need to be supported at the execution layer.

hopefully that helps.

Jacques

On Sat, Nov 17, 2012 at 1:05 PM, Jason <jasong@apache.org> wrote:

> I'm probably over thinking this. Don't mind my comment.
>
>
> On Sat, Nov 17, 2012 at 3:55 PM, Jacques Nadeau <jacques.drill@gmail.com
> >wrote:
>
> > I'm not sure I understand your question.  Can you expound a little bit?
> >
> > thanks,
> > Jacques
> >
> > On Sat, Nov 17, 2012 at 8:05 AM, Jason <jasong@apache.org> wrote:
> >
> > > How far do you guys forsee the need to go? What about some
> > > type/interpolation container like "#{0}" which 'may' allow some extras
> > like
> > > formatting etc... but such a thing could be too much. -J
> > >
> > >
> > > On Sat, Nov 17, 2012 at 8:00 AM, InJun Song <ijsong@gmail.com> wrote:
> > >
> > > > Seems good. To be more explicitly, we could refer variables by
> > appending
> > > $
> > > > mark.. For example,
> > > >
> > > > [
> > > >   { fn: "ref", ref: "user.gender"},
> > > >   { fn: "equals", val1: "$0", val2: "male"}
> > > >   { fn: "equals", val1: "$0", val2: "female"}
> > > >   { fn: "isnull", val1: "$0"}
> > > >   { fn: "case", cases: [
> > > >     { condition: "$1", output: ":/" },
> > > >     { condition: "$2", output: ":)"},
> > > >     { condition: "$3", output: ":("},
> > > >     { condition: "$4", output: ":o"}
> > > >   ]}
> > > > ]
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Nov 14, 2012 at 11:27 AM, Jacques Nadeau <
> > > jacques.drill@gmail.com
> > > > >wrote:
> > > >
> > > > > I've been working on blowing out some example logical plans.
> > > >  Originally, I
> > > > > was thinking that embedded expressions would be okay (see my
> previous
> > > > > email).  As I work through it, I think that utilizing ssa-ish
> > > > > representation makes more sense for the logical plan. An example
of
> > > this
> > > > > might be:
> > > > >
> > > > > Original Expression:
> > > > >
> > > > > left(regex("activity.cookie", "persistent=([^;]*)"), 3)
> > > > >
> > > > > New Expression
> > > > >
> > > > > [
> > > > >   { fn: "def", ref: "activity.cookie"},
> > > > >   { fn: "regex", val: "0", pattern: "persistent=([^;]*)"}
> > > > >   { fn: "left", val: "1", length: "3" }
> > > > > ]
> > > > >
> > > > > Everything becomes a function.  Even case statements.  For
> clarity, a
> > > > > function can receive nested arguments.
> > > > >
> > > > > CASE
> > > > >   WHEN user.gender='male' THEN ":/"
> > > > >   WHEN user.gender='female THEN ":)"
> > > > >   WHEN user.gender is null THEN ":("
> > > > >   ELSE ":o"
> > > > > END
> > > > >
> > > > > Becomes:
> > > > >
> > > > > [
> > > > >   { fn: "ref", ref: "user.gender"},
> > > > >   { fn: "equals", val1: "0", val2: "male"}
> > > > >   { fn: "equals", val1: "0", val2: "female"}
> > > > >   { fn: "isnull", val1: "0"}
> > > > >   { fn: "case", cases: [
> > > > >     { condition: "1", output: ":/" },
> > > > >     { condition: "2", output: ":)"},
> > > > >     { condition: "3", output: ":("},
> > > > >     { condition: "4", output: ":o"}
> > > > >   ]}
> > > > > ]
> > > > >
> > > > >
> > > > > Thoughts/Opinions?  To simplify, we could things like make single
> > value
> > > > > argument functions implicitly refer to the previous output if no
> > input
> > > is
> > > > > provided...
> > > > >
> > > > > Jacques
> > > > >
> > > >
> > >
> >
>

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