[
https://issues.apache.org/jira/browse/CASSANDRA-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13577178#comment-13577178
]
Jonathan Ellis commented on CASSANDRA-5182:
-------------------------------------------
I'm still not comfortable with this.
If our goal is to throw out the maximum possible amount of obsolete data, we
should perform getPosition across the board.
But if our goal is to be minimally impactful with compaction then we shouldn't
do it at all, and rely instead on the timestamp check. If that's not enough,
then you shouldn't disable bloom filters on workloads that perform deletes.
I'm okay with that message.
> Deletable rows are sometimes not removed during compaction
> ----------------------------------------------------------
>
> Key: CASSANDRA-5182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5182
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.7
> Reporter: Binh Van Nguyen
> Assignee: Yuki Morishita
> Fix For: 1.2.2
>
> Attachments: 5182-1.1.txt, 5182-1.2.txt, test_ttl.tar.gz
>
>
> Our use case is write heavy and read seldom. To optimize the space used,
> we've set the bloom_filter_fp_ratio=1.0 That along with the fact that each
> row is only written to one time and that there are more than 20 SSTables
> keeps the rows from ever being compacted. Here is the code:
> https://github.com/apache/cassandra/blob/cassandra-1.1/src/java/org/apache/cassandra/db/compaction/CompactionController.java#L162
> We hit this conner case and because of this C* keeps consuming more and more
> space on disk while it should not.
--
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
