[
https://issues.apache.org/jira/browse/CALCITE-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722908#comment-16722908
]
Stamatis Zampetakis commented on CALCITE-1536:
----------------------------------------------
Sometime ago I attempted piping the result of one VolcanoPlanner to another
VolcanoPlanner (each one having different rules) and I ended up seeing the
following AssertionError.
{code:java}
if (rel.getCluster().getPlanner() != this) {
throw new AssertionError("Relational expression " + rel
+ " belongs to a different planner than is currently being used.");
}
{code}
[~julianhyde] is this assertion related with this issue?
In the description of this issue you are saying that "it is difficult to use a
succession of planners for query planning". Since you are not saying impossible
I suppose there is workaround. Can you briefly sketch the general idea?
> Initialize cluster before planner
> ---------------------------------
>
> Key: CALCITE-1536
> URL: https://issues.apache.org/jira/browse/CALCITE-1536
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
> Priority: Major
>
> We should initialize the cluster ({{RelOptCluster}}) before planner
> ({{RelOptPlanner}}, or a sub-class such as {{VolcanoPlanner}} or
> {{HepPlanner}}). Currently the planner contains important information such as
> executor ({{RelOptPlanner.Executor}}), the set of active traits (epitomized
> by the {{RelOptPlanner.emptyTraitSet}} method) and the metadata providers,
> and the cluster contains a link to a planner, so the planner has to be
> created first.
> This makes it difficult to use a succession of planners for query planning.
> Fixing this issue is a first step towards CALCITE-1525.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
