[
https://issues.apache.org/jira/browse/CASSANDRA-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349056#comment-14349056
]
Benedict commented on CASSANDRA-8918:
-------------------------------------
Well, large is quite easy to define as "some multiple of the space required for
the stats" - but the tombstone histogram seems particularly problematic to
store partially upfront, so I'm rapidly losing interest in the fullest extent
of the idea. At the very least, though, this approach could be used to avoid
serialization costs when writing to disk, and might have a lower general CPU
burden by being able to offload the work to DMA via FileChannel.transferTo(). I
agree this is a lower likely yield than some of the other approaches we're
talking about
> 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)
