For #1, can you please give an example? For #2, I run the calcite UT, and they all passed. Is Durid test part of the UT? If not, how do I run them? Thanks.
> On Oct 28, 2019, at 7:57 PM, Danny Chan <yuzhao....@gmail.com> wrote: > > 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 > > > Best, > Danny Chan > 在 2019年10月29日 +0800 AM12:48，Xiening Dai <xndai....@gmail.com>，写道： >> 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, etc. >> >> 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?
