While debugging through some of the rules I'm trying to get to work, I find
that the matched relnode's input is *HepRelVertex* or a *RelSubset*.
Why wouldn't I be getting a descendant of the following types:
- BiRel
- MultiJoin
- SetOp
- SingleRel
- TableScan
There are other types
RelSubset provides a level of indirection that allows Calcite to optimize
queries. If the input to a relational operator is an equivalence class, not a
particular relational expression, then Calcite has the freedom to choose the
member of the equivalence class that has the cheapest cost.
Calcit
But how can I handle the unexpected variation of the input class type ?
For example, please consider the following *RelOptRule* constructor
public IncortaLimitRule() {
> super(operand(*DrillLimitRel*.class, operand(*IncortaJdbcDrel*.class,
> operand(*JdbcRel*.class, any(, "TestRule");
>
Consider ProjectFilterTransposeRule, a simple rule that matches a Project on
top of a Filter. But how to get that Project and Filter?
Run RelOptRulesTest.testPushProjectPastFilter in the debugger, and put a
breakpoint in ProjectFilterTransposeRule.onMatch [1]. Look at the Project
“origProj” in
Thanks a lot Julian. That was very helpful.
*-*
*Muhammad Gelbana*
On Thu, Jun 29, 2017 at 8:04 PM, Julian Hyde wrote:
> Consider ProjectFilterTransposeRule, a simple rule that matches a Project
> on top of a Filter. But how to get that Project and Filter?
>
> Run RelOptRule
I'm facing a similar problem but with Join inputs. Is there a way to
control the type of nodes returned as inputs to a join ? I wrote a rule for
a join but it failed to match it because I expect the join inputs to be
*JdbcRel* nodes while the inputs were actually *HepRelVertex*. I'm using
Drill.
Can you share your operand constraints? Where did you see HepRelVertex? As
Julian described, the rel nodes are of the correct type when matched with
operand constraints.
Jess
On Tue, Aug 1, 2017 at 7:25 AM, Muhammad Gelbana
wrote:
> I'm facing a similar problem but with Join inputs. Is there a
Here it is
> public GelbanaJoinRule(JdbcConvention out) {
> super(operand(LogicalJoin.class, Convention.NONE, any()),
> "GelbanaJoinRule");
> this.outConvention = out;
> }
The nodes appearing as *HepRelVertex* are the *LogicalJoin*'s input nodes,
not the operands passed to the rule using
Join has two inputs but you have only one “any()”. I am surprised that it is
matching a Join at all (an operand with one input should not match a RelNode
with two inputs). But given that it does… you have two operands, so call.rel(0)
and call.rel(1) will be valid but call.rel(2) will not.
So, h
Of course! You are correct. I got used to single input nodes and I didn't
deal with the Join properly.
I get the inputs of the join using *join.getInputs()*.
Thanks,
Gelbana
On Wed, Aug 2, 2017 at 8:10 PM, Julian Hyde wrote:
> Join has two inputs but you have only one “any()”. I am surprised
Yes, to repeat: don’t call RelNode.getInput(int), or RelNode.getInputs(), or
Join.getLeft() or Join.getRight(), or SingleRelNode.getInput(). If you do, you
will get the wrapped input, a HepRelVertex or a RelSubset.
Instead call RelOptRuleCall.rel(int).
Julian
> On Aug 2, 2017, at 1:34 PM, Mu
11 matches
Mail list logo
