cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-172) A improved and more general version of get_slice
Date Fri, 15 May 2009 23:00:45 GMT

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

Jonathan Ellis commented on CASSANDRA-172:
------------------------------------------

1. By "fetch more data" you mean "fetch exactly one extra column" because you pass the last
column returned as the start column for the next "page," right?  I think that is better than
having a separate offset parameter (especially since new columns could have been inserted,
and you are less likely to get "wrong" results when specifying a column name than an offset).

2. ok

3. Right, two separate indexes is definitely more in keeping with "the zen of cassandra" :)

4. That's true, which is an additional point in favor of doing CFs separately.  You have to
go through some contortions to return CF information along w/ each column block which is clunky
as well as inefficient (from re-copying out the CF wrapper and deserializing repeatedly).
 It will definitely be more performant to handle the CFs and IColumns separately and I think
overall it will end up simpler too.  If you like you can try making this change last and submit
both versions and if I am wrong we'll go with the CF wrapper in the iterator.

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


Mime
View raw message