cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4004) Add support for ReversedType
Date Mon, 16 Apr 2012 13:42:25 GMT

    [ 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

        

Mime
View raw message