[jira] [Comment Edited] (CASSANDRA-10862) LCS repair: compact tables before making available in L0

["Chen Shen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-10862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15313089#comment-15313089 ] 

Chen Shen edited comment on CASSANDRA-10862 at 6/2/16 9:37 PM:
---------------------------------------------------------------

Sorry for the late reply due to vacation. 
[~pauloricardomg] This is happening during streaming stage and we are on 2.2.5. So it seems CASSANDRA-6851 should have been included in this version and we should perform STCS on received sstables right? 

Also, l'm willing to jump on this if it's not your top priority :)


was (Author: scv119@gmail.com):
[~pauloricardomg] This is happening during streaming stage and we are on 2.2.5. So it seems CASSANDRA-6851 should have been included in this version and we should perform STCS on received sstables right? 

> LCS repair: compact tables before making available in L0
> --------------------------------------------------------
>
>                 Key: CASSANDRA-10862
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10862
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Compaction, Streaming and Messaging
>            Reporter: Jeff Ferland
>
> When doing repair on a system with lots of mismatched ranges, the number of tables in L0 goes up dramatically, as correspondingly goes the number of tables referenced for a query. Latency increases dramatically in tandem.
> Eventually all the copied tables are compacted down in L0, then copied into L1 (which may be a very large copy), finally reducing the number of SSTables per query into the manageable range.
> It seems to me that the cleanest answer is to compact after streaming, then mark tables available rather than marking available when the file itself is complete.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)