[
https://issues.apache.org/jira/browse/HIVE-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490475#comment-13490475
]
Mark Grover commented on HIVE-3652:
-----------------------------------
[~namitjain] Agreed. I would be fine with no backup join, at least in the first
pass.
[~amareshwari] Thanks for the response.
If we are going figure out fact and dimension tables by just looking at the
join keys and relative sizes of tables, there could be existing Hive queries
out there that might start failing (albeit by flipping of a property or
inclusion of a query hint) when they upgrade Hive. That's where I think having
a backup task would be nice because the queries will still continue to pass if
we have a backup task.
> Join optimization for star schema
> ---------------------------------
>
> Key: HIVE-3652
> URL: https://issues.apache.org/jira/browse/HIVE-3652
> Project: Hive
> Issue Type: Improvement
> Components: Query Processor
> Reporter: Amareshwari Sriramadasu
> Assignee: Amareshwari Sriramadasu
>
> Currently, if we join one fact table with multiple dimension tables, it
> results in multiple mapreduce jobs for each join with dimension table,
> because join would be on different keys for each dimension.
> Usually all the dimension tables will be small and can fit into memory and so
> map-side join can used to join with fact table.
> In this issue I want to look at optimizing such query to generate single
> mapreduce job sothat mapper loads dimension tables into memory and joins with
> fact table on different keys as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
