incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ravikumar Govindarajan <>
Subject Re: Composite Column Types Storage
Date Thu, 20 Sep 2012 11:28:58 GMT
As I understand from the link below, burning column index-info onto the
sstable index files will not only eliminate sstables but also reduce disk
seeks from 3 to 2 for wide rows.

Our index files are always mmapped, so there is only one random seek for a
named column query. I think that is a wonderful improvement

Shouldn't we be wary of the spike in heap usage by promoting column indexes
to index file?

It should be nice to have say 128th entry written out to disk, while load
every 512th index in memory during start-up, just as a balancing factor?


On Tue, Sep 18, 2012 at 4:47 PM, Sylvain Lebresne <>wrote:

> > Range queries do not use bloom filters. It holds good for
> composite-columns
> > also right?
> Since I assume you are referring to column's bloom filters (key's bloom
> filters
> are always used) then yes, that holds good for composite columns.
> Currently,
> composite column name are completely opaque to the storage engine.
> > <Column-part-1> alone could have gone into the bloom-filter, speeding up
> my
> > queries really effectively
> True, though (in 1.2
> only
> however) should help quite a lot here. Basically it will allow to skip the
> sstable based on the column index. Granted, this is less fined grained
> than a
> bloom filter (though on the other side there is no false positive), but I
> suspect that in most real life workload it won't be too much worse.
> --
> Sylvain

View raw message