You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "James Taylor (JIRA)" <ji...@apache.org> on 2015/09/21 20:35:05 UTC

[jira] [Updated] (PHOENIX-2283) Perf test Drill-based broadcast join versus Phoenix hash join

     [ https://issues.apache.org/jira/browse/PHOENIX-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Taylor updated PHOENIX-2283:
----------------------------------
    Labels: drill  (was: )

> 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
>              Labels: drill
>
> 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)