Mailing-List: contact issues-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@drill.apache.org
Date: Mon, 16 Mar 2015 19:47:38 +0000 (UTC)
From: "Jason Altekruse (JIRA)" <jira@apache.org>
To: issues@drill.apache.org
Message-ID: <JIRA.12774375.1423695335000.108073.1426535258231@Atlassian.JIRA>
In-Reply-To: <JIRA.12774375.1423695335000@Atlassian.JIRA>
References: <JIRA.12774375.1423695335000@Atlassian.JIRA>
 <JIRA.12774375.1423695335565@arcas>
Subject: [jira] [Updated] (DRILL-2218) Constant folding rule exposing
 planning bugs and not being used in plan where the constant expression is
 in the select list
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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)