[
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)