[
https://issues.apache.org/jira/browse/DRILL-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Altekruse updated DRILL-2218:
-----------------------------------
Description:
This test method and rule is not currently in the master branch, but it does
appear in the patch posted for constant expression folding during planning,
DRILL-2060. Once it is merged, the test
TestConstantFolding.testConstExprFolding_InSelect() which is currently ignored,
will be failing. The issue is that even though the constant folding rule for
project is firing, and I have traced it to see that a replacement project with
a literal is created, it is not being selected in the final plan. This seems
rather odd, as there is a comment in the last line of the onMatch() method of
the rule that says the following. This does not appear to be having the desired
effect, may need to file a bug in calcite.
{code}
// New plan is absolutely better than old plan.
call.getPlanner().setImportance(project, 0.0);
{code}
Here is the query from the test, I expect the sum to be folded in planning with
the newly enabled project constant folding rule.
{code}
select columns[0], 3+5 from cp.`test_input.csv`
{code}
There also some planning bugs that are exposed when this rule is enabled, even
if the ReduceExpressionsRule.PROJECT_INSTANCE has no impact on the plan itself.
It is causing a planning bug for the TestAggregateFunctions.testDrill2092 -as
well as TestProjectPushDown.testProjectPastJoinPastFilterPastJoinPushDown()-.
The rule's OnMatch is being called, but not modifying the plan. It seems like
its presence in the optimizer is making another rule fire that is creating a
bad plan.
was:
This test method and rule is not currently in the master branch, but it does
appear in the patch posted for constant expression folding during planning,
DRILL-2060. Once it is merged, the test
TestConstantFolding.testConstExprFolding_InSelect() which is currently ignored,
will be failing. The issue is that even though the constant folding rule for
project is firing, and I have traced it to see that a replacement project with
a literal is created, it is not being selected in the final plan. This seems
rather odd, as there is a comment in the last line of the onMatch() method of
the rule that says the following. This does not appear to be having the desired
effect, may need to file a bug in calcite.
{code}
// New plan is absolutely better than old plan.
call.getPlanner().setImportance(project, 0.0);
{code}
Here is the query from the test, I expect the sum to be folded in planning with
the newly enabled project constant folding rule.
{code}
select columns[0], 3+5 from cp.`test_input.csv`
{code}
There also some planning bugs that are exposed when this rule is enabled, even
if the ReduceExpressionsRule.PROJECT_INSTANCE has no impact on the plan itself.
It is causing a planning bug for the TestAggregateFunctions.testDrill2092 as
well as TestProjectPushDown.testProjectPastJoinPastFilterPastJoinPushDown().
The rule's OnMatch is being called, but not modifying the plan. It seems like
its presence in the optimizer is making another rule fire that is creating a
bad plan.
> Constant folding rule exposing planning bugs and not being used in plan where
> the constant expression is in the select list
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: DRILL-2218
> URL: https://issues.apache.org/jira/browse/DRILL-2218
> Project: Apache Drill
> Issue Type: Improvement
> Components: Query Planning & Optimization
> Reporter: Jason Altekruse
> Assignee: Aman Sinha
> Fix For: 0.9.0
>
>
> This test method and rule is not currently in the master branch, but it does
> appear in the patch posted for constant expression folding during planning,
> DRILL-2060. Once it is merged, the test
> TestConstantFolding.testConstExprFolding_InSelect() which is currently
> ignored, will be failing. The issue is that even though the constant folding
> rule for project is firing, and I have traced it to see that a replacement
> project with a literal is created, it is not being selected in the final
> plan. This seems rather odd, as there is a comment in the last line of the
> onMatch() method of the rule that says the following. This does not appear to
> be having the desired effect, may need to file a bug in calcite.
> {code}
> // New plan is absolutely better than old plan.
> call.getPlanner().setImportance(project, 0.0);
> {code}
> Here is the query from the test, I expect the sum to be folded in planning
> with the newly enabled project constant folding rule.
> {code}
> select columns[0], 3+5 from cp.`test_input.csv`
> {code}
> There also some planning bugs that are exposed when this rule is enabled,
> even if the ReduceExpressionsRule.PROJECT_INSTANCE has no impact on the plan
> itself.
> It is causing a planning bug for the TestAggregateFunctions.testDrill2092 -as
> well as TestProjectPushDown.testProjectPastJoinPastFilterPastJoinPushDown()-.
> The rule's OnMatch is being called, but not modifying the plan. It seems like
> its presence in the optimizer is making another rule fire that is creating a
> bad plan.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
