You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Lars Hofhansl (JIRA)" <ji...@apache.org> on 2016/07/03 01:53:11 UTC
[jira] [Comment Edited] (PHOENIX-2724) Query with large number of
guideposts is slower compared to no stats
[ https://issues.apache.org/jira/browse/PHOENIX-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360377#comment-15360377 ]
Lars Hofhansl edited comment on PHOENIX-2724 at 7/3/16 1:52 AM:
----------------------------------------------------------------
In {{BaseResultIterators.getParallelScans}} we do this:
{code}
estimatedRows += gps.getRowCounts().get(guideIndex);
estimatedSize += gps.getByteCounts().get(guideIndex);
{code}
Turns out that row and byte Counts are LinkedLists, which obviously get extremely slow for looking up by index when the list is large.
* some minor optimizations in BaseResultIterators
* the key change is in GuidePostsInfoBuilder. It was using a LinkedList.
was (Author: lhofhansl):
In {{BaseResultIterators.getParallelScans}} we do this:
{code}
estimatedRows += gps.getRowCounts().get(guideIndex);
estimatedSize += gps.getByteCounts().get(guideIndex);
{code}
Turns out that {{row|byte}Counts}} is a LinkedList, which obviously gets extremely slow for looking up by index when the list is large.
* some minor optimizations in BaseResultIterators
* the key change is in GuidePostsInfoBuilder. It was using a LinkedList.
> Query with large number of guideposts is slower compared to no stats
> --------------------------------------------------------------------
>
> Key: PHOENIX-2724
> URL: https://issues.apache.org/jira/browse/PHOENIX-2724
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.7.0
> Environment: Phoenix 4.7.0-RC4, HBase-0.98.17 on a 8 node cluster
> Reporter: Mujtaba Chohan
> Assignee: Samarth Jain
> Fix For: 4.8.0
>
> Attachments: 2724.txt, PHOENIX-2724.patch, PHOENIX-2724_addendum.patch, PHOENIX-2724_v2.patch
>
>
> With 1MB guidepost width for ~900GB/500M rows table. Queries with short scan range gets significantly slower.
> Without stats:
> {code}
> select * from T limit 10; // query execution time <100 msec
> {code}
> With stats:
> {code}
> select * from T limit 10; // query execution time >20 seconds
> Explain plan: CLIENT 876085-CHUNK 476569382 ROWS 876060986727 BYTES SERIAL 1-WAY FULL SCAN OVER T SERVER 10 ROW LIMIT CLIENT 10 ROW LIMIT
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)