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

Gabriel Reid resolved PHOENIX-561.
----------------------------------

    Resolution: Fixed

Bulk resolve of closed issues imported from GitHub. This status was reached by 
first re-opening all closed imported issues and then resolving them in bulk.

> Issue #20 - hashjoin implementation
> -----------------------------------
>
>                 Key: PHOENIX-561
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-561
>             Project: Phoenix
>          Issue Type: Task
>            Reporter: Maryann Xue
>
> 1. JoinCompiler:
>     Basically organizes conditions in "on clause" into three categories: a) 
> join conditions, b) pre-filters that can be done with scan filters; c) 
> post-filters that should be applied against the joined result.
>     Also provides facilities for re-constructing a subquery out of a join 
> table, testing star-join types, etc.
> 2. Runtime projection:
>     One of the biggest problem with join is column name conflicts in a joined 
> result. Currently we are using column family renaming strategy by prefixing 
> column families with its corresponding table name (or table alias name).
>     Since each KeyValue in the merged list of KeyValues from multiple tables 
> has to have identical RowKeys (for binary search in class Result), the 
> RowKeys of each KeyValue are replaced with a dummy/meaningless RowKey during 
> projection. Thus, RowKeys will already have been uniformed at join time.
>     As to the original RowKey itself, it will be transformed into a 
> independent KeyValue with a dummy RowKey, a tablename prefix as column 
> family, and the real RowKey as column value.
>     Hence, when a reference to a RowKey with tablename, it will be translated 
> into a KeyValueColumnExpression with an accessor instead of a 
> RowKeyColumnExpression.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to