[CALCITE-3923] Refactor how planner rules are parameterized

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.25.0
• Labels: pull-request-available
• Assignee: Julian Hyde
• Reporter: Julian Hyde
• Created: 14/Apr/20 21:01
• Updated: 03/Sep/21 00:52
• Resolved: 29/Jul/20 01:11

Description

People often want different variants of planner rules. An example is FilterJoinRule, which has a 'boolean smart’ parameter, a predicate (which returns whether to pull up filter conditions), operands (which determine the precise sub-classes of RelNode that the rule should match) and a RelBuilderFactory (which controls the type of RelNode created by this rule).

Suppose you have an instance of FilterJoinRule and you want to change smart from true to false. The smart parameter is immutable (good!) but you can’t easily create a clone of the rule because you don’t know the values of the other parameters. Your instance might even be (unbeknownst to you) a sub-class with extra parameters and a private constructor.

So, my proposal is to put all of the config information of a RelOptRule into a single config parameter that contains all relevant properties. Each sub-class of RelOptRule would have one constructor with just a ‘config’ parameter. Each config knows which sub-class of RelOptRule to create. Therefore it is easy to copy a config, change one or more properties, and create a new rule instance.

Adding a property to a rule’s config does not require us to add or deprecate any constructors.

The operands are part of the config, so if you have a rule that matches a EnumerableFilter on an EnumerableJoin and you want to make it match an EnumerableFilter on an EnumerableNestedLoopJoin, you can easily create one with one changed operand.

The config is immutable and self-describing, so we can use it to automatically generate a unique description for each rule instance.

(See the email thread [DISCUSS] Refactor how planner rules are parameterized.)

Issue Links

• fixes: CALCITE-3541 Avoid transformations to Enumerable nodes for custom SqlOperators
• is blocked by: CALCITE-4117 Release Calcite 1.24.0
• is duplicated by: CALCITE-4183 FilterSetOpTransposeRule constructor should allow for user defined Filter and SetOp classes
• is related to: HIVE-24756 Refactor CBO rules to exploit the new RelRule interface
• relates to: CALCITE-4759 JoinPushThroughJoinRule does not match two joins
• relates to: CALCITE-1166 Disallow sub-classes of RelOptRuleOperand
• relates to: CALCITE-4136 ReduceExpressionsRule.FILTER_INSTANCE cannot be initialized by some JVM
• relates to: CALCITE-2832 Create RuleOperandBuilder for building RelOptRule operands
• relates to: CALCITE-4079 Dialect constants in SqlDialect can cause class initialization deadlock
• links to: GitHub Pull Request #2024