cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Lebresne <>
Subject Re: Cassandra 1.2, wide row and secondary index question
Date Tue, 15 Jan 2013 08:09:40 GMT
On Mon, Jan 14, 2013 at 11:55 PM, aaron morton <>wrote:

> Sylvain,
> Out of interest if the select is…
> select * from  test where interval = 7  and severity = 3 order by id desc
> ;
> Would the the ordering be a no-op or would it still run ?

Yes, as Shahryar said this is currently rejected because ORDER BY is not
supported on 2ndary indexes queries (cause we don't know how to do them
efficiently). Tbh, the example here is a special case where we could, in
theory, support ORDER BY because the partition key is fixed by the query. I
guess that's a todo.

Or more generally does including an ORDER BY clause that matches the
> CLUSTERING ORDER BY DDL clause incur overhead?

In general no, there is no overheard. The one case where there is an
overhead is with queries where the partition key is an IN (i.e. when we do
the equivalent of a multiget), because in that case we do query all the
partitions and then merge sort the results. But in that case, not using an
ORDER BY will *not* yield the same result than using an ORDER BY that
matches the CLUSTERING ORDER BY, so I suppose it shouldn't come as a
surprise that there is an overhead.


> Cheers
> A
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> New Zealand
> @aaronmorton
> On 15/01/2013, at 6:56 AM, Sylvain Lebresne <> wrote:
> On Mon, Jan 14, 2013 at 5:04 PM, Shahryar Sedghi <>wrote:
>> Can I always count on this order, or it may change  in the future?
> I would personally rely on it. I don't see any reason why we would change
> that internally and besides I suspect you won't be the only one to rely on
> it so we won't take the chance of breaking it.
> However, I do note that this stands for Cassandra 2ndary indexes only.
> Internally, Cassandra has a notion of custom indexes (used by DataStax Solr
> integration for instance) and for those indexes the ordering might likely
> not be the same. So if you think you might switch your index to a solr one
> later on, then maybe it's worth trying to avoid relying on the ordering.
> --
> Sylvain
>> Thanks in Advance
>> Shahryar
>> --
>> "Life is what happens while you are making other plans." ~ John Lennon

View raw message