I can see how it would be somewhat useful to register a rule that match a
variety of patterns. However, the only efficient implementation I can imagine
would have multiple rule instances in the engine, each with a particular set of
operands directed at particular classes. Therefore this would be syntactic
sugar - kind of like how bash globs wildcards in file names and other
command-line arguments but the command sees the expanded arguments.
Another problem is how the rule identifies relational expressions. Suppose you
write a rule that matches both {Project -> Filter} and {Filter -> Project}. Now
you need to get those expressions. Remember that the matched relational
expression are retrieved by their ordinal in a tree-walk over the operands. So,
for the first rule variant you’d write
public void onMatch(RelOptRuleCall call) {
final Project p = call.rel(0);
final Filter f = call.rel(1);
but for the second you’d need
public void onMatch(RelOptRuleCall call) {
final Filter f = call.rel(0);
final Project p = call.rel(1);
And you’d also probably be interested in which variant matched. I expect that
you’d need a separate piece of handler code for each variant, and where better
to put the handler but in a separate instance (and anonymous sub-class) of the
rule?
Julian
> On Jul 13, 2017, at 8:04 AM, aka.fe2s <[email protected]> wrote:
>
> Clarification
>
> it should not apply **here**
>
> **Join** ->
> Join -> Project -> Filter -> TableScan
> Join -> Project -> Filter -> TableScan
>
> but should apply in the nested joins
>
> --
> Алексей
>
> On Thu, Jul 13, 2017 at 6:01 PM, aka.fe2s <[email protected]> wrote:
>
>> Hi,
>>
>> Can I somehow declare RelOptRule to apply only on top of any combination
>> of listed children without explicitly declaring all possible combinations?
>>
>> Example, I want to apply MyJoinRule only on top of [Project, Filter and
>> TableScan] in any combination.
>> It should apply on
>> 1) Join -> Project -> Filter -> TableScan
>> 2) Join -> Project -> TableScan
>> 3) Join -> Filter -> TableScan
>>
>> but it should not apply on
>>
>> Join ->
>> Join -> Project -> Filter -> TableScan
>> Join -> Project -> Filter -> TableScan
>>
>> The only way I found so far is to create many rules to explicitly declare
>> all supported trees.
>> I was looking into some() and unordered() methods without success.
>>
>> Is there any better ways?
>>
>> --
>> Oleksiy
>>
