[
https://issues.apache.org/jira/browse/CASSANDRA-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507260#comment-13507260
]
Sylvain Lebresne commented on CASSANDRA-4885:
---------------------------------------------
bq. On large rows we essentially only do slice queries
Now that I think about that, with CQL3, we do potentially do name queries on
wide rows fairly often (basically anytime you request just one CQL3 row in a
table that have a composite PK, and unless there is a collection). So maybe it
could be worth being a bit prudent with completely removing this too quickly.
For instance, maybe we could have a columnBF_fp_chance like for table-level BF
and recognize a special value of that (say, 1) as don't generate any BF at all?
That could even be the default, but at least someone that say often require to
test the existence of a CQL3 row in a table with composite PK could activate
the column BF and probably have some benefit from it.
> 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: 1.3
>
> 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: http://www.atlassian.com/software/jira
