Hi Jihoon, Sorry was silent on this. I am working on this now. On 17 Jul 2015 12:44, "Atri Sharma" <[email protected]> wrote:
> https://issues.apache.org/jira/browse/TAJO-1688 > > On Thu, Jul 16, 2015 at 5:59 PM, Jihoon Son <[email protected]> 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 <[email protected]>님이 작성: >> >> > Thanks. >> > >> > So what changes do you feel arr needed to implement this please? >> > On 16 Jul 2015 17:17, "Jihoon Son" <[email protected]> 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 >> > > [email protected]>님이 작성: >> > > >> > > > So after TAJO 680, the way IN is handled will change? >> > > > >> > > > On Thu, Jul 16, 2015 at 6:52 AM, Jihoon Son <[email protected]> >> > > 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 <[email protected]>님이 작성: >> > > > > >> > > > > > 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* >
