Thanks, Maryann. The sql used in test case is: select * from(select * from sales.emp where deptno = 10) where deptno + 5 > empno. Yes, I did debug the rule, it's fired on both tests. In Calcite's RelOptRulesTest::testPullConstantIntoFilter(), matched LogicalFilter's(deptno + 5 > empno) input is HepRelVertex which wraps the second LogicalFilter(deptno = 10), so the RelMetadataQuery would get constant from the second LogicalFilter(deptno = 10) and the rule would reduce the expression in the first LogicalFilter(deptno + 5 > empno ==> 15 > empno). While for the test in Flink, the matched LogicalFilter's(deptno + 5 > empno) input is RelSubset, I didn't find any information related to the second LogicalFilter(deptno = 10) inside. so RelMetadataQuery could not get constant from it, and neither reduce the expression in the first LogicalFilter. Do you have any clue about this?
Thanks Chengxiang -----Original Message----- From: Maryann Xue [mailto:[email protected]] Sent: Thursday, March 3, 2016 10:00 PM To: [email protected] Subject: Re: The difference between VolcanoPlaner and HepPlanner Hi Chengxiang, A simple answer is "no" to question #2. Would you mind sharing your test cases? It could sometimes be tricky playing with the VolcanoPlanner. My experience is 1) the final plan you see in which the rule(s) have not taken effect does not mean the rule(s) are not fired. Did you try setting a breakpoint in the rule itself? 2) it could be something wrong or inconsistent in the TraitSet (which is only used by VolcanoPlanner). 3) it could be inconsistency between the TraitSet and the MetaData you component has provided. Q1: HepPlanner is more like a pre-programmed query planner with a set of fixed instructions to run, e.g. applying a certain set of rules for a number of times. VolcanoPlanner is cost based. It applies all specified rules arbitrarily and does exhaustive search to find the cheapest query plan. Thanks, Maryann On Thu, Mar 3, 2016 at 6:00 AM, Li, Chengxiang <[email protected]> wrote: > Hi, all > Currently I'm trying to verify whether some Calcite built-in optimize > rules are working in Flink SQL, which depends on Calcite to parse and > optimize queries. During the verification, I found some optimize rule > does not work as expected(such as FilterReduceExpression), while it > works in Calcite's tests. With debugging, I found Flink use > VolcanoPlaner and Calcite tests use HepPlanner, it seems to be the > reason rule does not work, so my questions are: > > 1. What's the difference between VolcanoPlaner and HepPlanner? There > is no much information from JavaDoc. > > 2. Is there any Calcite built-in optimize rules that only support > VocanoPlaner or HepPlanner? > > 3. If #2 is true, is there any document or simple way to find > whether a Calcite built-in optimize rule support VocanoPlaner? > > Thanks > Chengxiang >
