[
https://issues.apache.org/jira/browse/BEAM-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904420#comment-16904420
]
Rahul Patwari commented on BEAM-6114:
-------------------------------------
[~amaliujia]
I have been exploring RelOptRule and ConverterRule. This is the summary of my
Exploration:
As we want to convert from "Convention.None" to
"BeamLogicalConvention.INSTANCE", we cannot use RelOptRule, which is used for
Optimizing the Query by modifying the order of Rel expressions.
Coming to ConverterRule, currently, there is no way to match a ConverterRule
based on operands(like RelOptRule, where a rule can be matched by specifying
the children[I was thinking that we can specify BeamRelNode as two child nodes
of LogicalJoin] of the RelNodes in the Constructor).
One way to create a ConverterRule for each type of join is to Implement a
predicate on LogicalJoin RelNode by following these steps:
* Get inputs of LogicalJoin RelNode
* Convert input RelNodes to BeamRelNodes, if inputs are not already an
instance of BeamRelNode. To convert from RelNode to BeamRelNode, we have to
find the type of Relnode and accordingly create instances of BeamRelNode.
* Check for Boundedness of the inputs and convert to specific BeamJoinRel
Instance.
Is this approach viable?
Do you prefer a better approach?
> SQL join selection should be done in planner, not in expansion to PTransform
> ----------------------------------------------------------------------------
>
> Key: BEAM-6114
> URL: https://issues.apache.org/jira/browse/BEAM-6114
> Project: Beam
> Issue Type: Improvement
> Components: dsl-sql
> Reporter: Kenneth Knowles
> Assignee: Rahul Patwari
> Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently Beam SQL joins all go through a single physical operator which has
> a single PTransform that does all join algorithms based on properties of its
> input PCollections as well as the relational algebra.
> A first step is to make the needed information part of the relational
> algebra, so it can choose a PTransform based on that, and the PTransforms can
> be simpler.
> Second step is to have separate (physical) relational operators for different
> join algorithms.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
