[
https://issues.apache.org/jira/browse/CASSANDRA-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13602390#comment-13602390
]
Jonathan Ellis commented on CASSANDRA-4885:
-------------------------------------------
[~slebresne] do you still think we should provide this as an option? After
letting it simmer for a couple months I'd still like to just rip it out:
- a rare simplification of our increasingly baroque storage engine code
- even if you're in the rare case of reading single (CQL) rows from a large
partition, it's far from clear that a BF is going to be a win for you, since
you have to deserialize the BF in its entirety to do any queries on it. So
probably only useful for "wide partitions, but not too wide." Pretty narrow
benefit and one I'll bet few users will get right.
- BF computation is part of the GC pain that LCR causes (CASSANDRA-5344)
> Remove or rework per-row bloom filters
> --------------------------------------
>
> Key: CASSANDRA-4885
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4885
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jason Brown
> Fix For: 2.0
>
> Attachments: 0001-CASSANRDA-4885-Remove-per-row-bloom-filter.patch,
> 0002-CASSANRDA-4885-update-test.patch, 4885-v1.patch
>
>
> Per-row bloom filters may be a misfeature.
> On small rows we don't create them.
> On large rows we essentially only do slice queries that can't take advantage
> of it.
> And on very large rows if we ever did deserialize it, the performance hit of
> doing so would outweigh the benefit of skipping the actual read.
--
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
