Re: Optimization around Multiple ORs and constants

[Atri Sharma <at...@gmail.com>]

Hi Jihoon,

Sorry was silent on this. I am working on this now.
On 17 Jul 2015 12:44, "Atri Sharma" <at...@gmail.com> wrote:

> https://issues.apache.org/jira/browse/TAJO-1688
>
> On Thu, Jul 16, 2015 at 5:59 PM, Jihoon Son <ji...@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 <at...@gmail.com>님이 작성:
>>
>> > Thanks.
>> >
>> > So what changes do you feel arr needed to implement this please?
>> > On 16 Jul 2015 17:17, "Jihoon Son" <ji...@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 <ji...@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 <at...@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*
>