[
https://issues.apache.org/jira/browse/PHOENIX-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16352053#comment-16352053
]
Maryann Xue edited comment on PHOENIX-1556 at 2/5/18 8:31 AM:
--------------------------------------------------------------
Could you please review the patch for me, [~jamestaylor]?
The {{CostBasedDecisionIT#testJoinStrategyXXX()}} tests are to verify and
demonstrate how join strategies are chosen in different scenarios.
The calculation of join costs is designed to follow the guidelines below:
# The build side is applied with more weight than the probe side in
calculating the cost of a hash-join, so the smaller table is guaranteed to be
the build side.
# If the build side exceeds the size limit
(QueryServices.MAX_SERVER_CACHE_SIZE_ATTRIB), the cost of hash-join is
infinitely large.
# The cost of sort-merge-join alone is guaranteed to be smaller than
hash-join. But when sorting is required to do a sort-merge-join, the cost of
the added "order-by" will be counted in the total cost and thus may make the
sort-merge-join operation as a whole more expensive.
# The {{QueryCompiler#compileJoinQuery()}} method will compare the costs of
the plans from all applicable join strategies and chose a local optimal. As a
result, with multiple joins (joins between more than two tables), a mix of join
strategies may be chosen as the final plan. For example, (A hash-join B)
sort-merge-join C.
was (Author: maryannxue):
Could you please review the patch for me, [~jamestaylor]?
> Base hash versus sort merge join decision on cost
> -------------------------------------------------
>
> Key: PHOENIX-1556
> URL: https://issues.apache.org/jira/browse/PHOENIX-1556
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: James Taylor
> Assignee: Maryann Xue
> Priority: Major
> Labels: CostBasedOptimization
> Attachments: PHOENIX-1556.patch
>
>
> At compile time, we know how many guideposts (i.e. how many bytes) will be
> scanned for the RHS table. We should, by default, base the decision of using
> the hash-join verus many-to-many join on this information.
> Another criteria (as we've seen in PHOENIX-4508) is whether or not the tables
> being joined are already ordered by the join key. In that case, it's better
> to always use the sort merge join.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
