> 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.
Yes.
> Shouldn't we be wary of the spike in heap usage by promoting column indexes
> to index file?
If you're t
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 wonder
> 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 th
> It is slowly dawning on me that I need a super-column to use column blooms
> effectively and at the same time don't want the entire sub-column list
> deserialized.
Queries by name use the row level bloom filter, regardless of the CF type.
> In fact, for my use-case I also do not need a colum
Yes Aaron, I was not clear about Bloom Filters. I was thinking about the
column bloom filters when I specify an absolute value for Part1 of the
composite column and a start/end value for Part2 of the composite column
It is slowly dawning on me that I need a super-column to use column blooms
effect
> Range queries do not use bloom filters.
Are you talking about row range queries ? Or a slice of columns in a row ?
If you are getting a slice of columns from a single row, a bloom filter is used
to locate the row.
If you are getting a slice of columns from a range of rows, the bloom filter i
Thanks for the clarification. Even though compression solves disk space
issue, we might still have Memtable bloat right?
There is another issue to be handled for us. The queries are always going
to be range queries with absolute match on part1 and range on part 2 of the
composite columns
Ex: Quer
> Is every / combination stored separately in disk
Yes, each combination is stored separately on disk (the storage engine
itself doesn't have special casing for composite column, at least not
yet). But as far as disk space is concerned, I suspect that sstable
compression makes this largely a non i
