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

Ryan Svihla edited comment on CASSANDRA-11153 at 2/10/16 9:13 PM:
------------------------------------------------------------------

Ok thinking about this is more, this is basically a "what is worse" option. 
Folks that need to do horrible paging queries because of some legacy interface 
that they pass around (http://foo.com/?page=9) will just read the whole 
partition and throw away the extra AKA lousy client side mode.

If we required this be an "ALLOW FILTERING" option, I think that would tag it 
as a bad idea, but still enable people to do something less horrible than what 
they're already doing.  For smaller partitions this should be plenty fast 
enough still.


was (Author: rssvihla):
Ok thinking about this is more, this is basically a "what is worse" option. 
Folks that need to do horrible paging queries because of some legacy interface 
that they pass around (http://foo.com/?page=9) will just read the whole 
partition and throw away the extra AKA lousy client side mode.

If we required this be an "ALLOW FILTERING" option, I think that would tag it 
as a bad idea, but still enable people to do something less horrible than what 
they're already doing.

> Row offset within a partition
> -----------------------------
>
>                 Key: CASSANDRA-11153
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11153
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Ryan Svihla
>            Priority: Minor
>
> While doing this across partitions would be awful, inside of a partition this 
> seems like a reasonable request. Something like:
> SELECT * FROM my_table WHERE bucket='2015-10-10 12:00:00' LIMIT 100 OFFSET 100
> with a schema such as:
> CREATE TABLE my_table (bucket timestamp, id timeuuid, value text, PRIMARY 
> KEY(bucket, id));
> This could ease pain in migration of legacy use cases and I'm not convinced 
> the read cost has to be horrible when it's inside of a single partition.
> EDIT: I'm aware there is already an issue 
> https://issues.apache.org/jira/browse/CASSANDRA-6511. I think the partition 
> key requirement is where we get enough performance to provide the flexibility 
> in dealing with legacy apps that are stuck on a 'go to page 8' concept for 
> their application flow without incurring a huge hit scanning a cluster and 
> tossing the first 5 nodes results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to