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