cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Brosius (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4023) Improve BloomFilter deserialization performance
Date Mon, 26 Mar 2012 21:34:25 GMT


Dave Brosius commented on CASSANDRA-4023:

no v3 has this bug

the problem is in the general case where RowIndexEntry.serializer.deserialize() is using the
hasPromotedIndexes code, the amount of data read is variable (assuming in this case the first
int read in deserialize can be non 0). Therefore in SSTableReader the code can no longer statically
predict when a particular key will be the last key.

> Improve BloomFilter deserialization performance
> -----------------------------------------------
>                 Key: CASSANDRA-4023
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: Joaquin Casares
>            Assignee: Yuki Morishita
>            Priority: Minor
>              Labels: datastax_qa
>             Fix For: 1.0.9, 1.1.0
>         Attachments: 4023.txt, cassandra-1.0-4023-v2.txt, cassandra-1.0-4023-v3.txt,
> The difference of startup times between a 0.8.7 cluster and 1.0.7 cluster with the same
amount of data is 4x greater in 1.0.7.
> It seems as though 1.0.7 loads the BloomFilter through a series of reading longs out
in a multithreaded process while 0.8.7 reads the entire object.
> Perhaps we should update the new BloomFilter to do reading in batch as well?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message