[
https://issues.apache.org/jira/browse/CALCITE-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15749207#comment-15749207
]
Julian Hyde commented on CALCITE-1536:
--------------------------------------
I've been thinking about this, and prototyping in
https://github.com/julianhyde/calcite/tree/1536-cluster, I think that there is
a hierarchy of state. The earliest things are more fundamental, and can't be
changed easily without changing everything after them:
* cost factory;
* type factory;
* trait definitions;
* executor;
* context (config, environment variables and so forth);
* global RelNode state (e.g. the set of correlating variables that occur
throughout the tree);
* rules (i.e. program);
* information derived from the rules (e.g. the conversion matrix made possible
by converter rules; the map of operands that determines what rules might be
fired when a RelNode of type R is registered);
* metadata provider(s);
* materializations;
* root rel node (i.e. what is being optimized);
* runtime state such as rule queues and equivalence sets;
* state that occurs during a firing of a rule, such as in-progress and cached
metadata results.
To fix this issue, we should move some of the earlier pieces of state into
RelOptCluster. Some of these will be set when the cluster is created and
thereafter immutable. Of the later ones, some will be set when the
RelOptPlanner is created and will be immutable.
Can we discuss the order that the various pieces of information are provided?
In particular, which things should be immutable in the cluster and planner. I
think:
* We might need to move the cost model later, so that different phases of
planning can optimize for different things.
* Similarly we might need to add a list of "enabled traits" to each planner
phase. They would nevertheless be a subset of the "trait definitions"
established earlier in the process.
* Collections of planner rules should be turned into immutable "programs", some
of which might be just immutable lists of rules.
* We want to make it quick to create a planner. If data structures derived from
programs (e.g. conversion matrices and operand state machines) are expensive to
create, let's create an immutable a "CompiledProgram" and cache that, thereby
amortizing the planner initialization cost.
(I originally added these comments to CALCITE-1499, but they're more
appropriate here.)
> 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)
