[
https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451394#comment-13451394
]
Aleksey Yeschenko commented on CASSANDRA-4542:
----------------------------------------------
Had a look at possibility of flush optimization. Not sure in can be done in a
clean way.
Memtable#writeSortedContents already has an optimization for cf-level deletions
- it won't write the obsolete columns, only the cf-level tombstone.
As the comment in there says, it's not safe to not write the tombstone even if
it's already past the gc grace period (the row might have columns in other
sstables and they won't be removed at compaction if we never write the
cf-tombstone).
It can only be omitted if we know for sure that there are no columns for this
row in any sstables and it's a tricky thing, esp. when you count in remote
nodes.
There is a different way though. batchlog is local and each write comes with a
new random uuid as key. So if there is a row in the memtable then we know that
there are no columns for the row in any sstables and can safely dismiss the
tombstone write as well - this will require some API changes to CFS/Memtable
though.
> add atomic_batch_mutate method
> ------------------------------
>
> Key: CASSANDRA-4542
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4542
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
> Reporter: Jonathan Ellis
> Assignee: Aleksey Yeschenko
> Fix For: 1.2.1
>
> Attachments: 4542-diff.txt, 4542-v4.txt, 4542-v5.patch,
> CASSANDRA-4542-4543-4544-v3.patch
>
>
> atomic_batch_mutate will have the same parameters as batch_mutate, but will
> write to the batchlog before attempting distribution to the batch rows'
> replicas.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
