[
https://issues.apache.org/jira/browse/CASSANDRA-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14280003#comment-14280003
]
Sylvain Lebresne commented on CASSANDRA-8603:
---------------------------------------------
bq. there is an additional byte that is creating a difference and thus the code
is not catching.
This is what is called the {{EOC}} in the code and that is what is
differenciate "the beginning of the given prefix" (the start of the range
tombstone) from "the end of the given prefix" (the stop of the range
tombstone). It's both expected and very much needed.
As I said earlier, the start and stop of a RangeTombstone are not expected to
be equal and in that sense this ticket is invalid. The one known exception
being an "empty" composite (the first of the log lines you pasted) but that is
special cased anyway to reuse the same singleton object (so the patch is not
helpful in that case).
Hence the log lines you pasted where {{start}} is actually equal to {{stop}}
are indeed weird and it would be interesting to track what produces them. But I
can't reproduce them and quickly checking at the places where we create new RT,
nothing jumped out as potential culprit. As this happens during compaction,
could you check which table is compacting?
> 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
> Labels: tombstone
> Attachments: cassandra-2.0.11-8603.txt, cassandra-2.1-8603.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)
