[
https://issues.apache.org/jira/browse/CALCITE-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15749842#comment-15749842
]
Maryann Xue edited comment on CALCITE-1499 at 12/14/16 11:39 PM:
-----------------------------------------------------------------
Julian, I agree with you on the list of state in the RelOptPlanner. I think
there should be a high-level definition for clear: to clear all the planning
state (basically the last two in your list). And meanwhile{{addRule()}} would
involve some state change (item 8: information derived from the rules), that's
probably part of the reason why rules should be cleared alongside I guess? But
I also feel like we should add a clearXXX method for each of the addXXX
methods, like clearMaterializations(), clearLattices(). One other question is
that when we call {{addRule()}}, part of the derived/state information comes
from the current trait def set, so it's assuming that {{addRelTraitDef()}}
should be called beforehead, so does it make sense (or is it possible) to make
traitset immutable?
was (Author: maryannxue):
Julian, I agree with you with the list of state in the RelOptPlanner. I can see
there can be high-level definition for clear: which is to clear all the
planning state (basically the last two in your list). And
meanwhile{{addRule()}} would involve some state change (item 8: information
derived from the rules), that's probably part of the reason why rules should be
cleared alongside I guess? But I also feel like we should add a clearXXX method
for each of the addXXX methods, like clearMaterializations(), clearLattices().
One other question is that when we call {{addRule()}}, part of the
derived/state information comes from the current trait def set, so it's
assuming that {{addRelTraitDef()}} should be called beforehead, so does it make
sense (or is it possible) to make traitset immutable?
> Exclude VolcanoPlanner's "originalRoot" from default planning process
> ---------------------------------------------------------------------
>
> Key: CALCITE-1499
> URL: https://issues.apache.org/jira/browse/CALCITE-1499
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.10.0
> Reporter: Maryann Xue
> Assignee: Maryann Xue
>
> The Calcite compilation framework runs a series of Programs for query
> planning. The default programs consist of some pre-processing HepPrograms,
> e.g., de-correlation, field-trimming, etc., the volcano planning program,
> and some post-processing HepPrograms. In {{Prepare.optimize()}},
> {{planner.setRoot()}} is called before running the programs. As a result, the
> original rel from sql-to-rel conversion becomes the "originalRoot" in the
> VolcanoPlanner, and the new rel from the pre-processing programs becomes the
> new "root". In some cases, we would only want to run volcano planning on the
> new root based on the assumption that the new root is the desired form after
> pre-processing. And if we have an option to turn off the planning of the
> original root, the planning space can be significantly reduced.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
