[
https://issues.apache.org/jira/browse/CALCITE-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840624#comment-15840624
]
Maryann Xue commented on CALCITE-1500:
--------------------------------------
[~julianhyde], I just committed changes to the PR, based on your review:
1. Moved {{List<RelOptMaterialization> materializations, List<RelOptLattice>
lattices}} to {{Program.run}}. Not sure if we should make a new struct wrapping
the parameters in {{Program.run}}, like trait-set, or even rules.
2. Added clearing materializations and lattices in {{RelOptPlanner}} and
{{VolcanoPlanner}}, since it will be more aligned with the changes made in
{{Programs.RuleSetProgram}}, although I believe eventually we should either
remove {{clear}} method or make {{clear}} method clear almost everything.
3. I kept {{getRules}} for I don't think it would do more harm than existing
{{getMaterializations}} and {{getLatticeByName}}. If we decide to make them
immutable members in RelOptPlanner in CALCITE-1536, we will still be good to
have these getter methods; and if we decide to remove them from RelOptPlanner,
we'll take these getter methods away altogether.
> 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)
