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:44:18 UTC
[jira] [Updated] (CALCITE-1098) Set Mergence trigger relNode
cyclical reference (ProjectMergeRule)
[ https://issues.apache.org/jira/browse/CALCITE-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
janelian updated CALCITE-1098:
------------------------------
Description:
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.
was:
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.
> 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)