[
https://issues.apache.org/jira/browse/HBASE-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926344#action_12926344
]
HBase Review Board commented on HBASE-3160:
-------------------------------------------
Message from: "Kannan Muthukkaruppan" <[email protected]>
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1103/#review1704
-----------------------------------------------------------
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/PriorityCompactionQueue.java
<http://review.cloudera.org/r/1103/#comment5620>
the comment around "if it is already present in the queue" needs to be
updated.
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/PriorityCompactionQueue.java
<http://review.cloudera.org/r/1103/#comment5621>
I think here and in this diff overall (as well as the log outputs)
readability will be much better if we flipped the sign of the priority... i.e.
higher values imply higher priority.
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
<http://review.cloudera.org/r/1103/#comment5619>
-1 and not Integer.MAX_VALUE?
If blocking store files is not specified (i.e. user can tolerate any number
of files), then as per your intent, don't you want PRIORITY_USER to be
higher-pri always?
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
<http://review.cloudera.org/r/1103/#comment5618>
I think we should state it here (or somewhere) explicitly that smaller
values implies higher priority.
- Kannan
> Compactions: Use more intelligent priorities for PriorityCompactionQueue
> ------------------------------------------------------------------------
>
> Key: HBASE-3160
> URL: https://issues.apache.org/jira/browse/HBASE-3160
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 0.89.20100924, 0.90.0
> Reporter: Nicolas Spiegelberg
> Assignee: Nicolas Spiegelberg
> Fix For: 0.90.0
>
> Attachments: HBASE-3160.patch
>
>
> One of the problems with the current compaction queue is that we have a very
> low granularity on the importance of the various compactions in the queue.
> If a StoreFile count exceeds 15 files, only then do we bump via enum change.
> We should instead look into more intelligent, granular priority metrics for
> choosing the next compaction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
