[jira] [Commented] (DRILL-2218) Constant folding rule exposing planning bugs and not being used in plan where the constant expression is in the select list
[
https://issues.apache.org/jira/browse/DRILL-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14641285#comment-14641285
]
Jason Altekruse commented on DRILL-2218:
An update on this issue after discussing with [~jni] and [~amansinha100]. The
cost model for project currently on considers the number of expressions
present, not the complexity of the expressions. Therefore the rule being fired
to reduce the expression is producing the correct rewritten project, but it is
not being selected because it is exposing the same cost value as the version of
the project where the full expression is still present.
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: 1.4.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)
[jira] [Commented] (DRILL-2218) Constant folding rule exposing planning bugs and not being used in plan where the constant expression is in the select list
[
https://issues.apache.org/jira/browse/DRILL-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14363776#comment-14363776
]
Jason Altekruse commented on DRILL-2218:
Updated comment, one of the tests was failing because of a column ordering
change, I just updated the expected string in the 2060 patch.
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)
