[
https://issues.apache.org/jira/browse/HBASE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573959#comment-13573959
]
Sergey Shelukhin commented on HBASE-7763:
-----------------------------------------
Then you'd compact two 5ks (which might be a good idea), then have 10k 20 20 20
and it will go on compacting 20s as intended.
On the other hand, without size sort, if there's 4k 5k 5k, it would presumably
turn into 4k 10k, and as data is added, 4k will never be compacted except in
case of major, is that correct?
I am +0.9 on sort, someone more experienced can chime in on the balance of
breaking the refguide thing versus optimizing this; in my opinion it's ok to
break it if it's configurable.
Also, when you make final patch is it possible to make the compare test into an
utility so that other ideas can be tested for default policy. Or it can be a
separate jira.
> Compactions not sorting based on size anymore.
> ----------------------------------------------
>
> Key: HBASE-7763
> URL: https://issues.apache.org/jira/browse/HBASE-7763
> Project: HBase
> Issue Type: Bug
> Components: Compaction
> Affects Versions: 0.96.0, 0.94.4
> Reporter: Elliott Clark
> Assignee: Elliott Clark
> Priority: Critical
> Fix For: 0.96.0, 0.94.6
>
> Attachments: HBASE-7763-trunk-TESTING.patch,
> HBASE-7763-trunk-TESTING.patch, HBASE-7763-trunk-TESTING.patch
>
>
> Currently compaction selection is not sorting based on size. This causes
> selection to choose larger files to re-write than are needed when bulk loads
> are involved.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
