calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jinfeng Ni <jinfengn...@gmail.com>
Subject Re: Transitioning rules from ProjectFactory etc. to RelBuilder
Date Wed, 23 Sep 2015 19:18:21 GMT
+1.

I have one question.  RelBuilder seems to be used in onMatch() method,
when a particular type of RelNode has to be created.  What about
RelOptRuleOperand in the constructor of rule? Let's say if we want to
rule to match only DrillProject, or HiveFilter. The current way seems to
be that we extend the rule by providing a different RelOptRuleOperand.

Can RelBuilder also have getFilterClass(), getProjectClass() etc, which
would be used to specify the rule patten matching?



On Tue, Sep 22, 2015 at 6:41 PM, Jacques Nadeau <jacques@apache.org> wrote:
> Agree on the utility of this. +1.
>
> On Tue, Sep 22, 2015 at 6:22 PM, John Pullokkaran <
> jpullokkaran@hortonworks.com> wrote:
>
>> This is useful, though Hive will have to do some refactoring.
>>
>> In past Hive had to copy bunch of rules to work around these issues.
>> Rules & relnodes for org.apache.calcite.rel.logical.* is a good example of
>> this.
>>
>>
>> John
>>
>> On 9/22/15, 5:14 PM, "Julian Hyde" <jhyde@apache.org> wrote:
>>
>> >I have started work on
>> >https://issues.apache.org/jira/browse/CALCITE-828 and my
>> >work-in-progress is in
>> >https://github.com/julianhyde/incubator-calcite/commits/828-rule-builder.
>> >
>> >This will be a big change to teams such as Hive and Drill. Now would
>> >be a good time to chime in.
>> >
>> >The plan is that every rule instance has a ProtoRelBuilder field from
>> >which a RelBuilder can be created to be used in an onMatch method. The
>> >RelBuilder contains factories for every kind of RelNode, so we won't
>> >have to keep plumbing new factories in to existing rules.
>> >
>> >There will be other advantages. RelBuilder is an easier and more
>> >concise way of creating relational expressions. It does some useful
>> >stuff for free, like flattening ANDs and eliminating identity
>> >projections. I'm seeing the volume of code decrease and a few minor
>> >plan improvements.
>> >
>> >I haven't yet found a good way to deal with the pattern where if, say,
>> >ProjectFactory is null the rule is to use Project.copy to create a
>> >Project of the same type.
>> >
>> >I'm keeping & deprecating the old rule constructors that take a
>> >variety of XxxFactory arguments.
>> >
>> >As always, we try to keep API compatibility and mark the old API
>> >
>> >  @Deprecated // to be removed before 2.0
>> >
>> >but the deprecated APIs are no longer tested and are likely to be
>> >flaky. We strongly suggest that you fix calls to deprecated APIs as
>> >soon as you upgrade to a more recent version of Calcite.
>> >
>> >Julian
>> >
>>
>>

Mime
View raw message