cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4536) Ability for CQL3 to list partition keys
Date Thu, 08 Nov 2012 07:38:16 GMT


Sylvain Lebresne commented on CASSANDRA-4536:

Let me note that in CQL3 a row that have no live column don't exist, so we can't really implement
this with a range slice having an empty columns list. Instead we should do a range slice with
a full-row slice predicate with a count of 1, to make sure we do have a live column before
including the partition key. The downside being that this won't 'just read the index file'.

On the longer run, it should be possible to optimize that further if we consider it worth
it by adding a 1 bit per key info in the sstable index saying 'is there at least one live
column for that key in that sstable' (we could even add that bit-per-key without augmenting
the on-disk index size if we want to by using the first bit of the key position (since we
use it as a signed long and thus the first bit is unused)).
> Ability for CQL3 to list partition keys
> ---------------------------------------
>                 Key: CASSANDRA-4536
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API
>    Affects Versions: 1.1.0
>            Reporter: Jonathan Ellis
>            Priority: Minor
>              Labels: cql3
>             Fix For: 1.2.1
> 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:

View raw message