[
https://issues.apache.org/jira/browse/CALCITE-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838496#comment-15838496
]
Maryann Xue commented on CALCITE-1500:
--------------------------------------
Thank you very much for the feedback, [~julianhyde]! I just added a comment on
CALCITE-1536. I agree with you that we need to wait for CALCITE-1536. I was
trying to get the planning workflow adjustment done for Calcite-Phoenix and was
wondering if we could use "RelOptPlanner.clear()" as a walk-around, although
I'm inclined to have RelOptPlanner immutable and discard "clear()" method at
all. I think it's hard to draw a clear line of what should be immutable and
what should not in RelOptPlanner and things may change in future. Besides, on
implementation level some states are dependent on others. Anyway, l'll chime in
on CALCITE-1536 and put this one off for now.
> 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)
