You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "janelian (JIRA)" <ji...@apache.org> on 2016/02/21 14:35:18 UTC

[jira] [Created] (CALCITE-1098) Set Mergence trigger relNode cyclical reference (ProjectMergeRule)

janelian created CALCITE-1098:
---------------------------------

             Summary: Set Mergence trigger relNode cyclical reference (ProjectMergeRule)
                 Key: CALCITE-1098
                 URL: https://issues.apache.org/jira/browse/CALCITE-1098
             Project: Calcite
          Issue Type: Bug
            Reporter: janelian
            Assignee: Julian Hyde


The issue is found in applying ProjectMergeRule. Following is the case which triggers the relNode's cyclical reference.

For instance suppose you have following set tree:

Set#2: Project
  rel#3:Subset#2.NONE
     rel#4:(‘a’) with input (rel#5:Subset#1.NONE)
Set#1: Project
  rel#5:Subset#1.NONE
     rel#6:(‘a’) with input (rel#7:Subset#0.NONE)
Set#0: TableScan
  rel#7:Subset#0.NONE
     rel#8:Dept

Project#2- Project#1 triggers the ProjectMerge Rule, then a new equivalent Project will be generated, such as, 
rel#9:(‘a’) with input (rel#7:Subset#0.NONE).

When the planner is registering rel#9,  it will try to find the equivalent relNode which is reserved in mapDigestToRel. In the above case, rel#6 would be found. The set#2 and set#1 would be merged, then the following is the set tree after mergeing:

Set#1: Project
   rel#5:Subset#1.NONE
     rel#4:(‘a’) with input (rel#5:Subset#1.NONE)
     rel#6:(‘a’) with input (rel#7:Subset#0.NONE)
Set#0: TableScan
   rel#7:Subset#0.NONE
     rel#8: Dept

rel#4's input is set#1, then there is a cyclical reference.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)