​Thanks a lot Weijie, I believe I'm very close now. I hope you don't mind
few more questions please:
1. The new rule you are mentioning is a physical rule ? So I should
implement the Prel interface ?
2. By "traversing the join to find the ScanRel"
- This sounds like I have to "search" for something. Shouldn't I just
work on transforming the left (i.e. DrillJoinRel's getLeft() method) and
right (i.e. DrillJoinRel's getLeft() method) join objects ?
- The "left" and "right" elements of the DrillJoinRel object are of
type RelSubset, not *ScanRel* and I can't find a type called *ScanRel*.
I suppose you meant *ScanPrel*, specially because it implements the
*Prel* interface that provides the *getPhysicalOperator* method.
3. What if multiple physical or logical rules match for a single node,
what decides which rule will be applied and which will be rejected ? Is it
the *AbstractRelNode.computeSelfCost(RelOptPlanner)* method ? What if
more than one rule produces the same cost ?
I'll go ahead and see what I can do for now before hopefully you may offer
more guidance. THANKS A LOT.
*---------------------*
*Muhammad Gelbana*
http://www.linkedin.com/in/mgelbana
On Wed, Mar 29, 2017 at 4:23 AM, weijie tong <[email protected]>
wrote:
> to avoid misunderstanding , the new equivalent ScanRel is to have the
> joined ScanRel nodes's GroupScans, as the GroupScans indirectly hold the
> underlying storage information.
>
> On Wed, Mar 29, 2017 at 10:15 AM, weijie tong <[email protected]>
> wrote:
>
> >
> > my suggestion is you define a rule which matches the DrillJoinRel RelNode
> > , then at the onMatch method ,you traverse the join children to find the
> > ScanRel nodes . You define a new ScanRel which include the ScanRel nodes
> > you find last step. Then transform the JoinRel to this equivalent new
> > ScanRel.
> > Finally , the plan tree will not have the JoinRel but the ScanRel. You
> > can let your join plan rule in the PlannerPhase.JOIN_PLANNING.
> >
>
