[
https://issues.apache.org/jira/browse/CASSANDRA-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14495910#comment-14495910
]
Benjamin Lerer commented on CASSANDRA-8603:
-------------------------------------------
When the {{RangeTombstone}} is initially created the 2 {{Composites}}
effectively reuse, when needed, the same {{ByteBuffer}}. The problem appear as
soon as the {{RangeTombstone}} is serialized. Each {{Composite}} is serialized
separatly and by consequence each composite will be deserialized as an
independent object.
If I am not mistaken the serialization will happen:
# when the range tombstone is transfered to another node (e.g. from the
coordinator to the node where the data are stored)
# when the data are written to the SSTable
I did a kick test using {{Jamm}} on 2.1 and it seems that in your test scenario
we could save 120 bytes per {{RangeTombstone}}.
[~slebresne] could you confirm my analysis?
Regarding the patch:
* I do not think that the patch modify the code at the right place. The fix
should be applied within the {{deserializeBody}} method instead of in the
constructor.
* In the 2.1 version the code create 2 {{BoundedComposites}}. One for checking
and one for the assignment.
> Cut tombstone memory footprint in half for cql deletes
> ------------------------------------------------------
>
> Key: CASSANDRA-8603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8603
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Dominic Letz
> Assignee: Dominic Letz
> Labels: tombstone
> Attachments: cassandra-2.0.11-8603.txt, cassandra-2.1-8603.txt,
> cassandra-2.1-8603_v2.txt, system.log
>
>
> As CQL does not yet support range deletes every delete from CQL results in a
> "Semi-RangeTombstone" which actually has the same start and end values - but
> until today they are copies. Effectively doubling the required heap memory to
> store the RangeTombstone.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
