[jira] [Commented] (CALCITE-1536) Initialize cluster before planner

["Maryann Xue (JIRA)" <ji...@apache.org>]

    [ 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)