[ https://issues.apache.org/jira/browse/PHOENIX-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101595#comment-15101595 ]
ASF GitHub Bot commented on PHOENIX-2417: ----------------------------------------- GitHub user ankitsinghal opened a pull request: https://github.com/apache/phoenix/pull/147 PHOENIX-2417 Compress memory used by row key byte[] of guideposts - Still need to tweak some copying of bytes - Having only these two test case failing currently ViewIT.testNonSaltedUpdatableViewWithIndex:129->BaseViewIT.testUpdatableViewWithIndex:85->BaseViewIT.testUpdatableViewIndex:158 expected:<6> but was:<2> ViewIT.testNonSaltedUpdatableViewWithIndex:129->BaseViewIT.testUpdatableViewWithIndex:85->BaseViewIT.testUpdatableViewIndex:158 expected:<6> but was:<2> You can merge this pull request into a Git repository by running: $ git pull https://github.com/ankitsinghal/phoenix master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/phoenix/pull/147.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #147 ---- commit 5ebcd9e2f100ab7eb15452e41ae27be8cbe4070e Author: Ankit Singhal <ankitsingha...@gmail.com> Date: 2016-01-15T10:30:23Z PHOENIX-2417 Compress memory used by row key byte[] of 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)