[
https://issues.apache.org/jira/browse/CALCITE-3917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17082807#comment-17082807
]
Danny Chen commented on CALCITE-3917:
-------------------------------------
If we can tweak the cost for HASH_JOIN for NO_HASH, USE_HASH (give a very
small factor), why can't we also give the prune node a penalty ?
Perviously i fire a patch to remove the physical transition rule from the rule
set if we use hint "NO_HASH", similar behavior like the node prone.
> 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)
