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)