[jira] [Comment Edited] (CALCITE-1500) Allow materialization-applied rels to run pre-processing programs

["Julian Hyde (JIRA)" <ji...@apache.org>]

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