[
https://issues.apache.org/jira/browse/CALCITE-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838474#comment-15838474
]
Maryann Xue commented on CALCITE-1536:
--------------------------------------
I'm having slightly different thoughts. Once we can have RelOptCluster created
first and independent of RelOptPlanner, can we assume that there will be no
need to create a RelOptPlanner in the "prepare" stage? The "optimize" would be
just a set of Programs running on the input rel, with each of them deciding
which rules, traits and materializations to enable (the information contained
in RelOptCluster will be unchanged and used throughout all Programs). Each
Program will create RelOptPlanner(s) as needed and RelOptPlanner itself will be
immutable too. If there is any structures that need to be reused, they can be
set as input of RelOptPlanner and Programs will keep track of their life cycles.
> 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
>
> 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
(v6.3.4#6332)
