You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Hequn Cheng (JIRA)" <ji...@apache.org> on 2018/11/18 08:25:00 UTC

[jira] [Created] (CALCITE-2683) ProjectMergeRule should not be performed when Nondeterministic udf has been referenced more than once

Hequn Cheng created CALCITE-2683:
------------------------------------

             Summary: ProjectMergeRule should not be performed when Nondeterministic udf has been referenced more than once
                 Key: CALCITE-2683
                 URL: https://issues.apache.org/jira/browse/CALCITE-2683
             Project: Calcite
          Issue Type: Bug
          Components: core
            Reporter: Hequn Cheng
            Assignee: Hequn Cheng


Currently, there are some merge rules for project, such as {{CalcMergeRule}}, {{ProjectMergeRule}}, and {{ProjectCalcMergeRule}}. I found that these merge rules should not be performed when Nondeterministic expression of the bottom project has been referenced more than once by the top project. Take the following test as an example:
{code:java}
  @Test public void testProjectMergeCalcMergeWithNonDeterministic() throws Exception {
    HepProgram program = new HepProgramBuilder()
            .addRuleInstance(FilterProjectTransposeRule.INSTANCE)
            .addRuleInstance(ProjectMergeRule.INSTANCE)
            .build();

    checkPlanning(program,
            "select name, a as a1, a as a2 from (\n"
                    + "  select *, rand() as a\n"
                    + "  from dept)\n"
                    + "where deptno = 10\n");
  }
{code}
The result plan is 
{code:java}
LogicalProject(NAME=[$1], {color:red}A1{color}=[RAND()], {color:red}A2{color}=[RAND()])
  LogicalFilter(condition=[=($0, 10)])
    LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
In the plan, {color:red}A1{color} may not equal to {color:red}A2{color} since the two projects are merged which is against the SQL.
One option to solve the problem is to disable these merge rules in such cases. What do you guys think? Any suggestions are greatly appreciated.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)