The clustering column is ordered per partition key.
So if for example I create the following table:
create table desc_test (
id text,
name text,
PRIMARY KEY (id,name)
) WITH CLUSTERING ORDER BY (name DESC );
I insert a few rows:
insert into desc_test (id , name ) VALUES ( 'abc', 'abc');
insert into desc_test (id , name ) VALUES ( 'abc', 'bcd');
insert into desc_test (id , name ) VALUES ( 'abc', 'aaa');
insert into desc_test (id , name ) VALUES ( 'fgh', 'aaa');
insert into desc_test (id , name ) VALUES ( 'fgh', 'bcd');
insert into desc_test (id , name ) VALUES ( 'fgh', 'abc');
And then read:
select * from desc_test;
id | name
-----+------
fgh | bcd
fgh | abc
fgh | aaa
abc | bcd
abc | abc
abc | aaa
(6 rows)
You can see that the data is properly ordered in descending mode, BUT
*for each partition key. *
So in order to achieve what you want, you will have to add the relevant
partition key for each select query.
Hope this helps
On Sun, Jul 15, 2018 at 2:16 PM, Soheil Pourbafrani <soheil.i...@gmail.com>
wrote:
> I created table using the command:
> CREATE TABLE correlated_data (
> processing_timestamp bigint,
> generating_timestamp bigint,
> data text,
> PRIMARY KEY (processing_timestamp, generating_timestamp)
> ) WITH CLUSTERING ORDER BY (generating_timestamp DESC);
>
>
> When I get data using the command :
> SELECT * FROM correlated_data LIMIT 1 ;
>
> I expect it return the row with the biggest field "generating_timestamp",
> but I got the same row every time I run the query, while row with bigger "
> generating_timestamp" exists. What's the problem?
>
