You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Benedict (JIRA)" <ji...@apache.org> on 2015/07/16 13:05:04 UTC

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

     [ https://issues.apache.org/jira/browse/CASSANDRA-9818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benedict resolved CASSANDRA-9818.
---------------------------------
    Resolution: Won't Fix

Since, as stated, this probably isn't even possible (at least, not without a much more specialised tree structure than I originally envisaged), closing as Won't Fix.

> 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)