[ https://issues.apache.org/jira/browse/CASSANDRA-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko updated CASSANDRA-4536: ----------------------------------------- Attachment: 4536.txt > Ability for CQL3 to list partition keys > --------------------------------------- > > Key: CASSANDRA-4536 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4536 > Project: Cassandra > Issue Type: New Feature > Components: API > Affects Versions: 1.1.0 > Reporter: Jonathan Ellis > Assignee: Aleksey Yeschenko > Priority: Minor > Labels: cql3 > Fix For: 2.0.1 > > Attachments: 4536.txt, cassandra-4536_1.1.0.patch, > cassandra-4536_1.2.2.patch, cassandra-4536_1.2.5.patch > > > It can be useful to know the set of in-use partition keys (storage engine row > keys). One example given to me was where application data was modeled as a > few 10s of 1000s of wide rows, where the app required presenting these rows > to the user sorted based on information in the partition key. The partition > count is small enough to do the sort client-side in memory, which is what the > app did with the Thrift API--a range slice with an empty columns list. > This was a problem when migrating to CQL3. {{SELECT mykey FROM mytable}} > includes all the logical rows, which makes the resultset too large to make > this a reasonable approach, even with paging. > One way to add support would be to allow DISTINCT in the special case of > {{SELECT DISTINCT mykey FROM mytable}}. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira