[
https://issues.apache.org/jira/browse/CASSANDRA-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-1207.
---------------------------------------
Resolution: Later
Fix Version/s: (was: 0.7.1)
Assignee: (was: Brandon Williams)
It's not as big a win as I thought at first -- computing the filter is a
one-time cost at flush or compaction. That part isn't a big deal. So we're
mostly concerned about reads -- and if you have a small enough row that
skipping the filter would be helpful, you can force it to be skipped by taking
advantage of "sliced rows starting at the beginning of the row skip the BF"
feature. Which leaves the use case where this still matters (random access of
a single column in a small row) pretty narrow.
> Don't write BloomFilters for skinny rows
> ----------------------------------------
>
> Key: CASSANDRA-1207
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1207
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Stu Hood
> Priority: Minor
> Attachments:
> 0001-Return-alwaysMatchingBloomFilter-for-0-length-filter.patch,
> 0002-Conditionally-write-the-row-bloom-filter.patch
>
>
> All rows currently contain a serialized BloomFilter, regardless of size. For
> smaller rows, it is much more efficient in space and CPU time to not write a
> BloomFilter, and to eagerly perform lookups against the existing columns.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
