cassandra-commits mailing list archives

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


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