[
https://issues.apache.org/jira/browse/CASSANDRA-11153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Svihla updated CASSANDRA-11153:
------------------------------------
Description:
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.
was:
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.
> 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)
