[
https://issues.apache.org/jira/browse/CALCITE-3917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17082802#comment-17082802
]
Haisheng Yuan commented on CALCITE-3917:
----------------------------------------
[~danny0405] Your problem is easy to fix with some trick. When user hints
NO_HASH, just give hash join a super large penalty, if hash join is still
selected, that mean it is the only choice. This is how Postgres deal with
disabling nestedloop join.
> Revive pruned node when a rule generates RelNode that is already pruned
> -----------------------------------------------------------------------
>
> Key: CALCITE-3917
> URL: https://issues.apache.org/jira/browse/CALCITE-3917
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Haisheng Yuan
> Priority: Major
>
> Manually pruning nodes in rule can be dangerous. e.g.:
> Logical transformation rule X matches RelNode A and generates RelNode B. Rule
> X thinks B is always better than A, prunes A in the rule. But if B is already
> in the MEMO, matched and pruned by another rule Y before X, and rule Y
> generates A. At the end, we may see CannotPlanException, because there is no
> available RelNode in the RelSet.
> In this case, we'd better revive the node that is already pruned out by
> planner, even this can bring additional rule apply and overhead, but better
> than failure to plan.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
