James Taylor created PHOENIX-2283:
-------------------------------------
Summary: Perf test Drill-based broadcast join versus Phoenix hash
join
Key: PHOENIX-2283
URL: https://issues.apache.org/jira/browse/PHOENIX-2283
Project: Phoenix
Issue Type: Sub-task
Reporter: James Taylor
Most of our parallelized units of work can be modeled as an HBase scan in
Phoenix (as that's what gets run at the end of the day for the client/server
RPC). It's annotated with attributes which the coprocessor uses to drive the
scan.
Our hash join is different, though, as it makes two scans that are coordinated
by the client, both parallelized. The first one is the smaller side and ends up
being cached in the region server. The second one then looks up the row in the
cache and returns the joined row.
How would this broadcast hash join be most appropriately modeled in the
Phoenix+Drill+Calcite world?
There may not be a big win of using our broadcast join versus Drills' as
Drill's may be faster given the representation they use.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
