If I understand correctly, you can try below steps: 1. Create a rule of Converter to convert child nodes to append external Convention; 2. Create a rule of RelOptRule to convert the parent node -- check the Convention of child node when matching
Is it applicable ? rahul patwari <rahulpatwari8...@gmail.com> 于2019年8月22日周四 下午11:18写道： > Hi, > > The properties of the child nodes correspond to the external Convention. > So, the child nodes have to be converted before the parent can be > transformed. > If the property doesn't match (or) if the property cannot be > determined(child node not converted), the rule cannot be applied. So, we > end up in "Not enough Rules to find the Cheapest Plan". > Is there a way to convert the Child nodes before the parent? > Can VolcanoPlanner be configured to work in bottom-up fashion? > > Regards, > Rahul > > On Thu, Aug 22, 2019 at 3:33 PM XING JIN <jinxing.co...@gmail.com> wrote: > > > I guess in Rahul's case, the child node of join should be converted > first, > > thus physical properties will be appended. > > But RelNode doesn't have a reference to parent, thus an independent > > RelOptRule is needed to convert LogicalJoin. > > Just as Michael said, you need to override the method of > RelOptRule#matches > > and check the properties of child node. > > > > Best, > > Jin > > > > Stamatis Zampetakis <zabe...@gmail.com> 于2019年8月21日周三 下午5:50写道： > > > > > The Volcano planner works in a top-down fashion. It starts by > > transforming > > > the root and move towards the leafs of the plan. Due to this when > > > transforming a logical join its inputs are still in the logical > > convention > > > so in principle they should not have any physical properties. > > > > > > Normally when the physical join algorithm is chosen the respective rule > > > should be responsible for demanding the inputs of the join to have > > certain > > > properties. > > > > > > Long story short, I think in your use case you should not make the rule > > > match based on the properties of the child nodes but it should match > > > unconditionally and if necessary demand some properties in its inputs. > > If I > > > remember well the EnumerableMergeJoinRule follows this approach so you > > can > > > have a look there. > > > > > > Best, > > > Stamatis > > > > > > On Tue, Aug 20, 2019, 5:07 PM Michael Mior <mm...@apache.org> wrote: > > > > > > > If you just want to control whether the rule gets applied, you can > > > > override RelOptRule#matches which canreturns a boolean indicating > > > > whether the rule should be applied. > > > > -- > > > > Michael Mior > > > > mm...@apache.org > > > > > > > > Le ven. 9 août 2019 à 08:48, rahul patwari > > > > <rahulpatwari8...@gmail.com> a écrit : > > > > > > > > > > Hi, > > > > > > > > > > We want to create a ConverterRule which converts the default > calling > > > > > Convention to external storage-specific calling convention > depending > > on > > > > the > > > > > Children nodes, like RelOptRule. > > > > > > > > > > For example, depending on the properties of the child nodes, we > want > > to > > > > > convert LogicalJoin to external system's specific Join > > implementation. > > > > > > > > > > Currently, ConverterRule > > > > > < > > > > > > > > > > https://github.com/apache/calcite/blob/5212d6c47e36995943f4d955a1714bf03eb08e7e/core/src/main/java/org/apache/calcite/rel/convert/ConverterRule.java#L75 > > > > > > > > > > cannot take Children and Child Policy is > > > > RelOptRuleOperandChildPolicy.ANY. > > > > > > > > > > What is the preferred way to achieve this task? > > > > > > > > > > Thanks, > > > > > Rahul > > > > > > > > > >
