tajo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jihoon Son <jihoon...@apache.org>
Subject Re: Optimization around Multiple ORs and constants
Date Thu, 16 Jul 2015 12:29:15 GMT
It would be enough that you write a new LogicalPlanRewriteRule. This new
class will find the condition which consists of multiple OR predicates for
a single column, and replace it with the IN predicate. The name of variable
which contains the conditions is usually "qual", so you can find it easily.

It should be noted that there are many operators which can have
qualifications such as SELECTION, SCAN, HAVING, etc. Fortunately,
predicates exist at only SELECTION operator before applying
FilterPushDownRule. So your new rewriting rule can be easily implemented if
it is applied before FilterPushDownRule.

Finally, please don't forget registering your new rewriting rule at
LogicalPlanRewriteRuleProvider.

Best regards,
Jihoon

2015년 7월 16일 (목) 오후 8:49, Atri Sharma <atri.jiit@gmail.com>님이 작성:

> Thanks.
>
> So what changes do you feel arr needed to implement this please?
> On 16 Jul 2015 17:17, "Jihoon Son" <jihoonson@apache.org> wrote:
>
> > Yes you can. Please feel free to create any issues on jira.
> >
> > To support in subquery, only its logical plan will be changed a little
> bit.
> > You can see the changes at https://github.com/apache/tajo/pull/620,
> > especially in InPredicate.java if I remember correctly. I can't check it
> > right now, so I'll tell you if I'm wrong.
> >
> > Jihoon
> >
> > 2015년 7월 16일 (목) 오후 7:36, Atri Sharma
> > atri.jiit@gmail.com>님이 작성:
> >
> > > So after TAJO 680, the way IN is handled will change?
> > >
> > > On Thu, Jul 16, 2015 at 6:52 AM, Jihoon Son <jihoonson@apache.org>
> > wrote:
> > >
> > > > Nice idea!
> > > > Our evaluation of non-subquery IN predicates employs the hash
> approach,
> > > it
> > > > would be much faster.
> > > >
> > > > To do such work, you may need to create a new logical plan rewriter.
> We
> > > > have a plan rewriting system which consists of LogicalOptimizer,
> > > > LogicalPlanRewriteRule, and LogicalPlanRewriteRuleProvider.
> > > > LogicalOptimizer optimizes the initial query plan according to the
> > > rewrite
> > > > rules provided by LogicalPlanRewriteRuleProvider. We currently have
> > three
> > > > LogicalPlanRewriteRules of FilterPushDownRule,
> ProjectionPushDownRule,
> > > and
> > > > PartitionedTableRewriter. After
> > > > https://issues.apache.org/jira/browse/TAJO-680,
> InSubqueryRewriteRule
> > > will
> > > > be added for in-subquery rewriting. If you want to start this work,
> > these
> > > > will be good examples.
> > > >
> > > > As always, please feel free to ask any questions If you have.
> > > >
> > > > Best regards,
> > > > Jihoon
> > > >
> > > > 2015년 7월 16일 (목) 오전 2:37, Atri Sharma <atri.jiit@gmail.com>님이
작성:
> > > >
> > > > > Hi,
> > > > >
> > > > > For cases like WHERE col1=val1 OR col1=val2 OR col1=val3 OR
> col1=val4
> > > OR
> > > > > col1=val5 where val1,val2,val3,val4,val5 are constants, do we do
> any
> > > > > optimizations? I can imagine conversion to
> > IN(val1,val2,val3,val4,val5)
> > > > > which will be more optimized.
> > > > >
> > > > > --
> > > > > Regards,
> > > > >
> > > > > Atri
> > > > > *l'apprenant*
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Atri
> > > *l'apprenant*
> > >
> >
>

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