[
https://issues.apache.org/jira/browse/CALCITE-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17030874#comment-17030874
]
Stamatis Zampetakis commented on CALCITE-3753:
----------------------------------------------
[~hyuan] the API that I was talking is still under design. I have a few ideas
but unfortunately I didn't have time to pull out a working prototype. My idea
is that the traits in a {{RelSubset}} can be though of as the requirement.
Given that all relational expressions in a set are equivalent it suffices to
look at the traits of the contained subsets to see what was requested by the
parent. Given that the subsets appear to be re more or less topologically
sorted I was thinking that it may be possible to handle trait propagation like
that.
Anyways, I don't want to block this case till I find time to work on this new
API, so you can proceed as you see fit.
> Always try to match and execute substitution rule first and remove rulematch
> ordering
> -------------------------------------------------------------------------------------
>
> Key: CALCITE-3753
> URL: https://issues.apache.org/jira/browse/CALCITE-3753
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Haisheng Yuan
> Priority: Major
> Attachments: image-2020-01-27-20-27-57-957.png
>
>
> In VolcanoPlanner, some rules e.g. ProjectMergeRule, PruneEmptyRule can be
> defined as SubstitutionRule, so that we can always try to match and execute
> them first (without deferring rule call). All the other rulematches doesn't
> need to be sorted and rules can be executed in any order they matched, since
> we are going to execute all of them anyway, sooner or later. Computing and
> comparing importances cause a lot of latency.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
