[
https://issues.apache.org/jira/browse/CASSANDRA-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13817818#comment-13817818
]
Jonathan Ellis commented on CASSANDRA-5936:
-------------------------------------------
bq. curious why this logic is only? run for L0 compactions
This is actually flush logic, not compaction. So that makes more sense now.
Created CASSANDRA-6323 for this since it's not the same problem that Marcus is
talking about in the description here.
> Improve the way we pick L0 compaction candidates
> ------------------------------------------------
>
> Key: CASSANDRA-5936
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5936
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Marcus Eriksson
> Assignee: Marcus Eriksson
> Fix For: 2.1
>
>
> We could improve the way we pick compaction candidates in level 0 in LCS.
> The most common way for us to get behind on compaction is after repairs, we
> should exploit the fact that the streamed sstables are most often very narrow
> in range since the other nodes in the ring will have a similar
> sstable-range-distribution. We should in theory be able to do 10 concurrent
> compactions involving L1 - ie, partition L0 in buckets defined by the
> sstables in L1 to only keep one L1 SSTable busy for every compaction (be it
> L1 to L2 or L0 to L1).
> we will need some heuristics on when to select candidates from the buckets
> and when to do it the old way (since L0 sstables can span several L1 sstables)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
