cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8918) Optimise compaction performance for unique partition keys
Date Thu, 05 Mar 2015 15:09:38 GMT


Sylvain Lebresne commented on CASSANDRA-8918:

We used to do that but ended up removing it because 1) there is a fair amount of cases where
it's not desirable/not possible (when there is tombstones, expired columns or 2ndary indexes
on the table) and 2) because there is some of our sstable stats that we wouldn't be able to
properly update in that case (and for most of the stats, we would have to use a possibly too
pessimistic value for the whole sstable which is not a good thing).

I think 1) can be reconsidered if we think there is still a fair amount of situation where
it would help, but I think 2) is a serious blocker.

> Optimise compaction performance for unique partition keys
> ---------------------------------------------------------
>                 Key: CASSANDRA-8918
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>             Fix For: 3.0
> Related to the raft of improvements we're looking at for improving the CPU burden of
merge, if we can demonstrate that an entire partition key is unique to a given file (which
is quite easily done) we can avoid materialising any of the row, and simply copy the data
wholesale, with potentially some small modifications to the index file data if it has clustering
column index entries, and special treatment of tombstones (most simple would be to only check
there are no tombstones to purge, and abort this approach if so).

This message was sent by Atlassian JIRA

View raw message