[
https://issues.apache.org/jira/browse/FLINK-9997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16571512#comment-16571512
]
Fabian Hueske commented on FLINK-9997:
--------------------------------------
Hi [~RuidongLi], thanks for opening this issue.
You are of course right. Project and Filter nodes are translated into Calc
nodes during logical optimization. Hence, the Calc normalizer rule will never
match before logical optimization.
However, I'd like to avoid adding a new optimization phase. We have quite a few
phases already and I don't think we should fragment the optimization process
even more.
Did you consider the following alternatives:
- Move the normalization phase after the logical optimization? Since, Project
and Filter are always converted to Calc, it should not be a problem that the
respective normalization rules cannot be applied anymore.
- Add the Calc normalization to the logical optimization rules.
Out of curiosity, did you observe plans the performed bad because of the
missing Calc normalization?
> Improve Expression Reduce
> -------------------------
>
> Key: FLINK-9997
> URL: https://issues.apache.org/jira/browse/FLINK-9997
> Project: Flink
> Issue Type: Improvement
> Components: Table API & SQL
> Reporter: Ruidong Li
> Assignee: Ruidong Li
> Priority: Major
> Labels: pull-request-available
>
> There's no Calc node at normalize plans, so ReduceExpressionRule.CALC does
> not match any thing.
> If adding calc-related rules to normalize phase, then project-related rules
> and filter-related rules do not match any thing at logical opt phase. If
> adding ReduceExpressionRule.CALC to logical opt phase, it will increase the
> the search time. Therefore, adding a new phase after logical opt may be an
> option.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
