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

Jonathan Ellis commented on CASSANDRA-5745:
-------------------------------------------

bq. If you meant that we'd include only L+1 overlaps that meets the criteria of 
"more purgable tombstone that the threshold", i.e. that we'd basically just 
make tombstone compaction better at purging tombstone, then I'm definitively 
for it

That would have to be a pretty high threshold, because you have a pretty narrow 
window of "either the result must fit in L, or you must include all overlaps 
from L+1."

bq. If you meant we've include all L+1 overlaps no matter what, I am worried 
about the added overhead in general.

I think we'd need to add more complexity then -- "first try just dropping 
tombstones from the sstable by itself, then if that doesn't get it below the 
threshold merge it into L+1."

Minhash from CASSANDRA-6474 would let us get more sophisticated than just 
"merge into L+1" -- we could say, "merge with the top 10 most-overlapping 
sstables from any level and drop the result back down to L0."

> Minor compaction tombstone-removal deadlock
> -------------------------------------------
>
>                 Key: CASSANDRA-5745
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5745
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Jonathan Ellis
>             Fix For: 2.0.4
>
>
> From a discussion with Axel Liljencrantz,
> If you have two SSTables that have temporally overlapping data, you can get 
> lodged into a state where a compaction of SSTable A can't drop tombstones 
> because SSTable B contains older data *and vice versa*. Once that's happened, 
> Cassandra should be wedged into a state where CASSANDRA-4671 no longer helps 
> with tombstone removal. The only way to break the wedge would be to perform a 
> compaction containing both SSTable A and SSTable B. 



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Reply via email to