[
https://issues.apache.org/jira/browse/CASSANDRA-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710434#action_12710434
]
Jonathan Ellis commented on CASSANDRA-172:
------------------------------------------
1. still a strong -1 on this
3. My understanding is that there can only be one instance of a key per sstable
(b/c of how flush works) and for each key you have first the column index, then
the columns serialized contiguously (b/c of how CF.serializerWithIndexes
works). Therefore all columns for a given key/CF pair are in a single block
(group of keys that are indexed together as the term is used in the header of
SSTable). So (a) how can we need multiple seeks to read columns from a single
key, and (b) isn't this tremendously overcomplicated? I thought this was
fixing the "must deserialize all of the CF at once" problem but on second look
it mostly does not. What am I missing? Are we using the word block to mean
different things as I initially thought?
4/5. The CF wrapper still seems like the opposite of simple here to me but let
us see how 3 shakes out.
> A improved and more general version of get_slice
> ------------------------------------------------
>
> Key: CASSANDRA-172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-172
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Jun Rao
> Assignee: Jun Rao
> Fix For: 0.4
>
> Attachments: get_slice_from.patchv1, get_slice_from.patchv2
>
>
> Today, get_slice has to scan through all columns in every memtable and
> sstable to get a slice of columns. This becomes inefficient when the number
> of columns in a row is large. We need a more efficient API.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
