calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Chan <>
Subject Re: Same rules fired for logical and physical nodes
Date Tue, 29 Oct 2019 02:57:41 GMT
Thanks Xiening Dai for bringing up this topic ~

I agree that for most of the planning rules, only matching logical nodes are enough. There
are 2 concerts from my side:

• We have some plan rewrite that indeed happens on the “physical” node, so some the
rules may be still useful for such case, i.e. the ProjectMergeRule
• I’m a little worried about the compatibility, maybe we can rule the test cases like
Apache Druid which give us more confidence that this is the right way to go

Danny Chan
在 2019年10月29日 +0800 AM12:48,Xiening Dai <>,写道:
> Hi all,
> While I was looking at CALCITE-2970, I noticed that some of the rules are fired for both
logical and physical nodes. For example, ProjectMergeRule matches Project.class, so it’s
fired for LogicalProject. But then after LogicalProject is converted into EnummerableProject,
the same rule is fired again for the physical rels. Same for EnumerableLimitRule, SortRemoveConstantKeysRule,
> This seems to be unnecessary. When ProjectMerge is applied to LogicalProject nodes, we
already generate all possible alternatives with merged projects. We just need to convert the
LogicalProject into EnumerableProject. There’s no need to merge EnumerableProject again.
> If I update those rules to only match logical nodes, the planning time of the case in
CALCITE-2970 is reduced ~30%.
> Any thoughts?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message