[ 
https://issues.apache.org/jira/browse/PHOENIX-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16653791#comment-16653791
 ] 

Lars Hofhansl commented on PHOENIX-4974:
----------------------------------------

I think the difference is the following:

With the current code even as regions split and merge we can still make sure 
that there will be no gaps in the key range, since we move from region end to 
the start of the next region. (the ranges may no longer match to regions, but 
that's OK, Phoenix will refetch region infos on demand)

Getting all regions involves a scan through META, I'd need to convince myself 
that the same is true there. Since daughter regions sort *after* their parent I 
think it's OK.
[~apurtell], WDYT



> Gets all regions uses get requests is extremely slows for big table 
> --------------------------------------------------------------------
>
>                 Key: PHOENIX-4974
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4974
>             Project: Phoenix
>          Issue Type: Improvement
>    Affects Versions: 4.14.0, 5.0.0
>            Reporter: Jaanai
>            Assignee: Jaanai
>            Priority: Blocker
>         Attachments: PHOENIX-4974-master.patch, performance.png
>
>
> When executes the first query after started the client(SQLline or 
> initializing JDBC client ),  needs to load region locations to the client 
> cache.   Now the following is key implement :
> {code:java}
> List<HRegionLocation> locations = Lists.newArrayList();
>                 byte[] currentKey = HConstants.EMPTY_START_ROW;
>                 do {
>                     HRegionLocation regionLocation = 
> connection.getRegionLocation(
>                             TableName.valueOf(tableName), currentKey, reload);
>                     locations.add(regionLocation);
>                     currentKey = regionLocation.getRegionInfo().getEndKey();
>                 } while (!Bytes.equals(currentKey, HConstants.EMPTY_END_ROW));
> {code}
> For some big tables which have more than ten thousand regions,  this 
> procedure is extremely slow. 
> Runs a look points query on the table that has 10000 regions after starting 
> the client, it needs 25+ seconds.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to