drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Altekruse (JIRA)" <j...@apache.org>
Subject [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
Date Sat, 25 Jul 2015 00:23:04 GMT

    [ https://issues.apache.org/jira/browse/DRILL-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

View raw message