[
https://issues.apache.org/jira/browse/PHOENIX-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16607430#comment-16607430
]
Bin Shi commented on PHOENIX-4594:
----------------------------------
[~jamestaylor], [~abhishek.chouhan],
When I look at the origin problem in this JIRA, I'm very confused about one
thing. The Jira was opened because of the following experiment results from
Abhishek. Because the SQL statement is "select(*) from T" without pruning
([~abhishek.chouhan], could you confirm?), I doubt using linear search instead
of binary search for where the intersection begins is the root cause of this
particular case. The root cause seems to be that we go through all guide posts
and generate scan for every guide post and the amount of guide posts is just
too big. It seems to me that using such small GUIDE_POST_WIDTH is meaningless.
I do agree that changing from linear search to binary search helps when the
scan range is pruned to a small range.
----------------->
Time it takes for executing explain select(*) from T
|*Guide Posts Width*|*Number of Guideposts generated*|*Explain Plan Execution
Time (seconds)*|
|-|-|0.1|
|300MB|3139|1|
|50MB|18927|3|
|10MB|94685|4|
|{color:#d04437}1MB{color}|{color:#d04437}944921{color}|{color:#d04437}10{color}|
> Perform binary search on guideposts during query compilation
> ------------------------------------------------------------
>
> Key: PHOENIX-4594
> URL: https://issues.apache.org/jira/browse/PHOENIX-4594
> Project: Phoenix
> Issue Type: Improvement
> Reporter: James Taylor
> Assignee: Abhishek Singh Chouhan
> Priority: Major
>
> If there are many guideposts, performance will suffer during query
> compilation because we do a linear search of the guideposts to find the
> intersection with the scan ranges. Instead, in
> BaseResultIterators.getParallelScans() we should populate an array of
> guideposts and perform a binary search.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
