Github user chenghao-intel commented on the pull request: https://github.com/apache/spark/pull/7379#issuecomment-122188991 Sorry, I shouldn't use the word `SMJ`. I mean if we are planning to improve the performance of RangeJoin, probably we can think of it in a more general way, not just binary ConjunctivePredicates, but also for arbitrary-nary predicates. e.g. `join on a.key < b.key` `join on a.key < b.key and a.key2 > b.key2 and a.key3>=b.key3` ... I just have kind of feeling, maybe it will be more helpful/easy if we specify the same `RangePartitioner` (range key as the sorted key) for table(s), and then make the Cartesian Product for partitions. And the binary BroadcastRangeJoin just a specific case, and definitely lots of code can be shared (like the binary search for the closest tuple). Sorry if I misunderstood something.
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- --------------------------------------------------------------------- To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org For additional commands, e-mail: reviews-h...@spark.apache.org