tajo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Atri Sharma <atri.j...@gmail.com>
Subject Re: Optimization around Multiple ORs and constants
Date Fri, 17 Jul 2015 07:14:05 GMT
https://issues.apache.org/jira/browse/TAJO-1688

On Thu, Jul 16, 2015 at 5:59 PM, Jihoon Son <jihoonson@apache.org> wrote:

> 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*
> > > >
> > >
> >
>



-- 
Regards,

Atri
*l'apprenant*

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