This is probably a bigger discussion, but let me kick it off here anyway. Some of our planner rules have public constructors with Class arguments, and therefore people can create their own rule instances that match particular sub-classes. Other planner rules do not have those public constructors, and therefore are hard-wired to accept logical RelNodes (e.g. LogicalProject) or the base RelNode (e.g. Project).
The reason that the latter, less modern, rules still exist is that it is a big task to refactor all existing rules, and so it hasn’t been done yet. Is there a change we could make to the rule API that would make it easier to customize rules? I have been thinking for a while about adding an “operand builder” to replace the static methods (e.g. RelOptRule.operandJ) that we use to build the operands inside rules. Maybe as part of this change, we could allow rules to clone themselves with slightly different parameters. I’m interested in hearing about a “big change” that would save us from a myriad of small changes in the coming years. Julian > On Oct 28, 2019, at 7:57 PM, Danny Chan <[email protected]> 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 <[email protected]>，写道： >> 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?
