[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254684#comment-13254684
]
Sylvain Lebresne commented on CASSANDRA-4004:
---------------------------------------------
bq. but I don't think it makes sense for CQL.
Why wouldn't it? The notion of what is largest or smallest only make sense
once you've defined what ordering you're talking about (what I'm calling the
logical ordering). We do still allow in CQL custom orderings (which is useful),
so why giving a simple syntax to define the reverse ordering or an existing one
wouldn't make sense? With my first patch, "ORDER BY X DESC" does *always*
return the largest X first, given the ordering.
bq. but it shouldn't change the semantics of the query itself
To be precise, it doesn't change the semantic of the query, it changes the
logical ordering (which happens to be the same than the physical one but that
last part is an implementation detail) of records in the table.
Now, looking more closely at the alternative of keeping the logical ordering
unchanged but changing the physical ordering (in order to get faster reversed
queries), I think this just doesn't work. And by "doesn't work", I mean that as
soon as we have composites, it would be costly to implement (making it
useless). Typically, suppose you follow that idea and declare:
{noformat}
CREATE TABLE timeseries (
key text,
kind int,
time timestamp,
value text,
PRIMARY KEY (key, kind, time)
) WITH CLUSTERING ORDER BY (kind ASC, time DESC)
{noformat}
Now, if the query is:
{noformat}
SELECT kind, time FROM timeseries WHERE key = <somevalue> LIMIT 200;
{noformat}
then, if the DESC above is "just an optimisation for reversed queries, then the
expected result is (say):
{noformat}
kind | time
-----------
0 | 0
0 | 1
...
0 | 99
0 | 100
1 | 0
1 | 1
1 | 2
...
{noformat}
but the physical layout is now in fact:
{noformat}
kind | time
-----------
0 | 100
0 | 99
...
0 | 1
0 | 0
1 | 100
1 | 99
1 | 98
...
{noformat}
I don't see how to implement that query efficiently (without potentially making
many queries).
Lastly, while I think that changing the logical ordering is the correct way to
deal with this, the question of the syntax is another matter. I do happen to
like the syntax in the description of this ticket, but I don't care too much
either.
> Add support for ReversedType
> ----------------------------
>
> Key: CASSANDRA-4004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4004
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Trivial
> Fix For: 1.1.1
>
> Attachments: 4004.txt
>
>
> It would be nice to add a native syntax for the use of ReversedType. I'm sure
> there is anything in SQL that we inspired ourselves from, so I would propose
> something like:
> {noformat}
> CREATE TABLE timeseries (
> key text,
> time uuid,
> value text,
> PRIMARY KEY (key, time DESC)
> )
> {noformat}
> Alternatively, the DESC could also be put after the column name definition
> but one argument for putting it in the PK instead is that this only apply to
> keys.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
