[
https://issues.apache.org/jira/browse/CASSANDRA-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13142580#comment-13142580
]
Pavel Yaskevich commented on CASSANDRA-3427:
--------------------------------------------
yes but that will also imply that we should weight it in memory size instead of
number of entries so need to use jamm which is calculation overhead, better
just remove unused because we know precisely when to do that...
> CompressionMetadata is not shared across threads, we create a new one for
> each read
> -----------------------------------------------------------------------------------
>
> Key: CASSANDRA-3427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3427
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.0
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Labels: compression
> Fix For: 1.0.2
>
> Attachments: 3427.patch
>
>
> The CompressionMetada holds the compressed block offsets in memory. Without
> being absolutely huge, this is still of non-negligible size as soon as you
> have a bit of data in the DB. Reallocating this for each read is a very bad
> idea.
> Note that this only affect range queries, since "normal" queries uses
> CompressedSegmentedFile that does reuse a unique CompressionMetadata instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
