[
https://issues.apache.org/jira/browse/CALCITE-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15685188#comment-15685188
]
Julian Hyde commented on CALCITE-1500:
--------------------------------------
I fully support making the {{Program}} API (or related APIs) able to express
this kind of thing. If it helps, we can change the signature of
{{run(RelOptPlanner planner, RelNode rel, RelTraitSet requiredOutputTraits)}};
the current arguments happened without much great thought.
> 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)
