[
https://issues.apache.org/jira/browse/CALCITE-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15836432#comment-15836432
]
Julian Hyde edited comment on CALCITE-1500 at 1/24/17 6:33 PM:
---------------------------------------------------------------
I'm not sure we should be baking any session state into a Program. So, for
instance, we should not add {{List<RelOptMaterialization> materializations,
List<RelOptLattice> lattices}} parameters to the {{Programs.standard()}}. Maybe
we need to discuss changing the {{Program.run}} interface. In fact we need to
complete the discussion in CALCITE-1536 and figure out which state we believe
should belong to the program, the planner, the rel node tree, and which should
be passed into and out of the {{Program.run}} method.
Comments:
* I am concerned that making getRules() and ENUMERABLE_RULES public will make
it more difficult to refactor in future
* Please use "Returns ..." rather than "Return ..." in method javadoc
* How about renaming MaterializationOptUtil to RelOptMaterializations?
* The Pair of Pair data structure you are passing to Hook.PROGRAM is unwieldy.
Either define a struct with 3 fields, or create a Tuple3 class (analogous to
Pair).
* Please rename {{testSubquery}} to {{testSubQuery}}. I am trying to
standardize on sub-query being two words.
was (Author: julianhyde):
I'm not sure we should be baking any session state into a Program. So, for
instance, we should not add {{List<RelOptMaterialization> materializations,
List<RelOptLattice> lattices}} parameters to the {{Programs.standard()}}. Maybe
we need to discuss changing the {{Program.run}} interface. In fact we need to
complete the discussion in CALCITE-1536 and figure out which state we believe
should belong to the program, the planner, the rel node tree, and which should
be passed into and out of the {{Program.run}} method.
Comments:
* I am concerned that making getRules() and ENUMERABLE_RULES public will make
it more difficult to refactor in future
* Please use "Returns ..." rather than "Return ..." in method javadoc
* How about renaming MaterializationOptUtil to RelOptMaterializations?
* The Pair of Pair data structure you are passing to Hook.PROGRAM is unwieldy.
Either define a struct with 3 fields, or create a Tuple3 class (analogous to
Pair).
> Allow materialization-applied rels to run pre-processing programs
> -----------------------------------------------------------------
>
> Key: CALCITE-1500
> URL: https://issues.apache.org/jira/browse/CALCITE-1500
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.10.0
> Reporter: Maryann Xue
> Assignee: Maryann Xue
>
> VolcanoPlanner now takes the "originalRoot" as the input for
> materialized-view substitution, so the programs used in
> {{Prepare.optimize()}} will not be applied to these substituted rels. For
> example, a correlated subquery will be de-correlated but its equivalents with
> materialization substitutions will not be de-correlated. So it would be nice
> to have a way for the substituted rels to run specific programs too before
> starting volcano planning.
> The easiest solution might be using the new "root" for materialization
> substitution instead, but it would be based on the assumption that those
> "pre-processing" programs are simple ones like de-correlation and
> field-trimming. In order to allow a more general pre-processing program set,
> one that could have different optimization output for the original rel and
> for the materialization substituted rels, we'd better have an interface or
> some approach to run pre-processing programs for rels after materialization
> substitution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
