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

ASF GitHub Bot commented on PHOENIX-2417:
-----------------------------------------

Github user JamesRTaylor commented on a diff in the pull request:

    https://github.com/apache/phoenix/pull/147#discussion_r49880903
  
    --- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/schema/stats/GuidePostsInfo.java 
---
    @@ -53,22 +70,21 @@
          * @param guidePosts
          * @param rowCount
          */
    -    public GuidePostsInfo(long byteCount, List<byte[]> guidePosts, long 
rowCount) {
    -        this.guidePosts = ImmutableList.copyOf(guidePosts);
    -        int size = 0;
    -        for (byte[] key : guidePosts) {
    -            size += key.length;
    -        }
    -        this.keyByteSize = size;
    +    public GuidePostsInfo(long byteCount, ImmutableBytesWritable 
guidePosts, long rowCount, int maxLength, int guidePostsCount) {
    +        this.guidePosts = guidePosts;
    --- End diff --
    
    Best to make a copy of the ImmutableBytesWritable here in case the caller 
uses the ptr again. Note that this doesn't copy the underlying bytes:
    
        this.guidePosts = new ImmutableBytesWritable(guidePosts);


> Compress memory used by row key byte[] of guideposts
> ----------------------------------------------------
>
>                 Key: PHOENIX-2417
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2417
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: James Taylor
>            Assignee: Ankit Singhal
>             Fix For: 4.7.0
>
>         Attachments: PHOENIX-2417.patch, PHOENIX-2417_encoder.diff, 
> PHOENIX-2417_v2_wip.patch
>
>
> We've found that smaller guideposts are better in terms of minimizing any 
> increase in latency for point scans. However, this increases the amount of 
> memory significantly when caching the guideposts on the client. Guidepost are 
> equidistant row keys in the form of raw byte[] which are likely to have a 
> large percentage of their leading bytes in common (as they're stored in 
> sorted order. We should use a simple compression technique to mitigate this. 
> I noticed that Apache Parquet has a run length encoding - perhaps we can use 
> that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to