[
https://issues.apache.org/jira/browse/CASSANDRA-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14348842#comment-14348842
]
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: https://issues.apache.org/jira/browse/CASSANDRA-8918
> 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
(v6.3.4#6332)
