calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jul...@hydromatic.net>
Subject Consistent naming for planner rules
Date Thu, 11 Sep 2014 22:59:17 GMT
As the number of rules grows, it becomes more difficult to find out whether a similar rule
has already been added. The fact that there are several ways to name a rule adds to the confusion.

For instance, consider a rule that converts ‘join(project(x), project(y))’ into ‘project(join(x,
y))’. The actual rule is called PullUpProjectsAboveJoinRule but it could equally be called
PushJoinThroughProjectsRule.

There are lots of rules called PushXxxThroughYyyRule, too.

I propose the naming convention <Reltype1><Reltype2>[…]<Verb>Rule, where
ReltypeN is the class of the Nth RelNode matched, in depth-first order, ignoring unimportant
operands, and removing any ‘Rel’ suffix
Verb is what happens — typically Transpose, Swap, Merge, Optimize.

Thus:
PullUpProjectsAboveJoinRule becomes JoinProjectTransposeRule
PushAggregateThroughUnionRule becomes AggregateUnionTransposeRule
MergeProjectRule becomes ProjectMergeRule
MergeFilterOntoCalcRule becomes FilterCalcMergeRule
EnumerableJoinRule remains EnumerableJoinRule (Or how about JoinAsEnumerableRule?)
SwapJoinRule becomes JoinSwapInputsRule

I’d like to hear what people think of these names. What happens if you apply this naming
convention to rules you have created?

If there is consensus that this is an improvement, let’s rename the existing rules as part
of https://issues.apache.org/jira/browse/OPTIQ-296.

The naming convention would of course be optional. Rule authors would not need to follow it
if they don’t feel that it makes things clearer. 

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