[ 
https://issues.apache.org/jira/browse/CASSANDRA-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710006#action_12710006
 ] 

Jun Rao commented on CASSANDRA-172:
-----------------------------------

1. Regarding the start parameter in the api. 
One of the applications of this api is to support an index scan query. Then, 
(start, count) is the equivalent of (offset,limit) in mysql for this query. 
Without this, the client may have to fetch more data simply to throw some of 
them away. I suggest that we keep start and set its default value to 0. What do 
you think?

2. Regarding the terminology "block" used in SSTable.
The ColumnSliceBlockReader returned in SSTable is actually returning a block of 
columns at a time. This is because the column index within a row is a block 
index.

3. Regarding the isAscending parameter. 
I agree that going backwards could have worse performance. I can take that out. 
The implication is that if an application needs to scan an index in both 
directions, two separate indexes may have to be created.

4. Regarding Cursor and ColumnIterator returning a CF, instead of a Column.
The reason that ColumnIterator returns a CF containing a single column is to 
deal with the possibility that a CF itself can be marked deleted. If 
ColumnIterator only returns Column, then we need to deal with CF deletion 
separately and this is likely not as clean as the current approach.

Agree with the rest of the comments. Will submit a new patch.


> 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
>
>
> 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.

Reply via email to