RelBuilderFactory (and RelBuilder) is concerned with creating RelNodes not matching rules, so doesn’t seem the right place for the getConvention() method.
Also, I try not to give Convention special treatment that is not given to other traits. I wonder whether this could be generalized to other traits? Say, that a rule matches only if the matched RelNodes are have the same trait. Does this problem occur in VolcanoPlanner or only in HepPlanner? In VolcanoPlanner, DrillUnion would not be an input to JdbcFilter (it might be in a different RelSubset of the same RelSet, but not the same RelSubset), and therefore I don’t think the rule would fire. Julian > On Jan 28, 2019, at 1:11 PM, Vladimir Sitnikov <[email protected]> > wrote: > > Hi, > > I'm playing with CALCITE-2223 "ProjectMergeRule is infinitely matched when > is applied after ProjectReduceExpressionsRule", and I think I have an idea > re improvement of rule declarations. > > Current problem: super(operand(Filter.class, operand(SetOp.class, ..,)), > relBuilderFactory, ...) can fire for very weird arguments like > "JdbcFilter(DrillUnion(...))" > I'm sure it is not something rule author intended. On top of that it is one > of the sources for "infinite planning" issues. > > Of course we can always override "matches" method and/or use operandJ, > however it is really hard to do right. > > Suggestion: add getConvention method to RelBuilderFactory, so the rules > fires for a single convention only. > > Any thoughts? > > Longer post is here: > https://issues.apache.org/jira/browse/CALCITE-2223?focusedCommentId=16754345&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16754345 > > > PS. I think CALCITE-2223 is pretty much feature complete (it passes Calcite > and Drill tests), so I'm inclined to commit it modulo some cleanup. > However I would really prefer to add RelBuilderFactory#getConvention as > well. > > Vladimir
