[jira] [Commented] (CASSANDRA-9818) Merge RangeTombstoneList with row collections

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

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

Sylvain Lebresne commented on CASSANDRA-9818:
---------------------------------------------

I absolutely agree we should explore this, being able to store range tombstones and rows together would be really great. I would however strongly suggest delaying that exploration post-3.0. It won't be a trivial or even a small patch and we definitively don't have the cycles available to explore, develop, review and test such issue in time to meet our 3.0 deadline. And there is in particular no particular reasons not to do this post-3.0 (it's entirely internal implementations, so there won't be any backward compatibility issue or anything).

> Merge RangeTombstoneList with row collections
> ---------------------------------------------
>
>                 Key: CASSANDRA-9818
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9818
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Assignee: Benedict
>
> If BTree were to offer some relatively simple support for _ranges_, we could encode both range tombstones and rows in the same data structure. This would permit us pretty significant algorithmic benefits, but also should help with e.g. the atomicity of local updates to a materialized view, without the necessity of partition-level locks, as well as reducing our LoC count and simplifying the read of a btree partition (no merging of the two sets).
> If it's possible to do alongside the rollout of 3.0 and 8099, I would like to explore this, to see if we can eliminate RangeTombstoneList altogether. This may go hand-in-hand with the elimination of AbstractThreadUnsafePartition, in favour of a Builder -> BTreePartition.



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