[
https://issues.apache.org/jira/browse/HBASE-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926170#action_12926170
]
HBase Review Board commented on HBASE-3160:
-------------------------------------------
Message from: "Nicolas" <[email protected]>
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1103/#review1696
-----------------------------------------------------------
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/CompactSplitThread.java
<http://review.cloudera.org/r/1103/#comment5608>
@Stack you're completely correct. remember that we have splits turned off,
so I wasn't thinking in that vein. I think we want to unconditionally remove
and then add only if(just_removed && !splitting)
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
<http://review.cloudera.org/r/1103/#comment5609>
exactly. that is how blockingStoreFile decisions are made right now. this
will also make it easy to transition to per-store compactions in the future.
- Nicolas
> 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
>
>
> 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.
