Thanks Jinfeng and Jason, I have solved my problem, the reason is that the planner I used hasn’t been set an executor.
Thanks for your advice again! - Jark Wu > 在 2016年6月15日，下午1:26，Jinfeng Ni <[email protected]> 写道： > > If you put ReduceExpressionsRule in a HepPlanner, then you do not have > to rely the costing factor, since HepPlanner is heuristic-rule based, > not cost-based. > > Actually, Calcite has one unit test in RelOptRuleTest [1] [2], which > shows how constant reduce rules work. > > [1] > https://github.com/apache/calcite/blob/master/core/src/test/java/org/apache/calcite/test/RelOptRulesTest.java#L834 > [2] > https://github.com/apache/calcite/blob/master/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml#L644-L667 > > > On Tue, Jun 14, 2016 at 10:10 PM, Jason Altekruse <[email protected]> wrote: >> The first place I would recommend looking is how you are costing projects >> and filters. If the costing function for these relational operators does >> not take into account the complexity of the expressions contained, possibly >> by only considering the number of top level expressions, the reduced plan >> would not be exposing with a lower cost that it is preferable to the >> original plan. >> >> You can see here that the default project Rel appears to only consider the >> number of expressions and the input size when computing costs [1]. You >> probably want to have some visitor that will walk each of the expressions >> to come up with a more accurate cost. I don't know if this functionality is >> provided somewhere else in calcite. >> >> [1] - >> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/core/Project.java#L216 >> >> Jason Altekruse >> Software Engineer at Dremio >> Apache Drill Committer >> >> On Tue, Jun 14, 2016 at 9:58 PM, Jark Wu <[email protected]> wrote: >> >>> Hi all, >>> >>> I want to reduce the constant expression in sql, replacing them with a >>> corresponding constant. >>> >>> For instance I have a sql query : >>> >>> SELECT a, b, c+(2+3) as d FROM Orders WHERE b > (1+4) >>> >>> >>> I want some planner rules can optimize this query to reduce the constant >>> exprssions: >>> >>> SELECT a, b, c+5 as d FROM Orders WHERE b > 5 >>> >>> >>> It seems that ReduceExpressionsRule is what I need, and I tried it many >>> times but it didn’t work. >>> >>> Is the way I used wrong ? Or there is any exist rule to use, or I have to >>> implement one myself ? >>> >>> >>> >>> - Jark Wu >>>
