cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9818) Merge RangeTombstoneList with row collections
Date Thu, 16 Jul 2015 10:45:05 GMT


Benedict commented on CASSANDRA-9818:

bq. Let's be honest a minute: we are already not within the timescales we want to be in.

Yes, and the codebase is in a state where almost every line of code has been changed, and
mostly not properly reviewed. Updates that reduce our exposure to new code by replacing a
lot of new code with less new code, that is potentially easier to reason about, are a good
thing to consider. Not just with 8099 new code, but materialized views introducing locks into
the system (always a dangerous addition), that this would avoid.

But either way: I've already stated I don't even expect to do that, so why are we arguing
over this? 

> Merge RangeTombstoneList with row collections
> ---------------------------------------------
>                 Key: CASSANDRA-9818
>                 URL:
>             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

View raw message