cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4885) Remove or rework per-row bloom filters
Date Thu, 14 Mar 2013 16:24:14 GMT


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:
>             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,
> 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:

View raw message