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? >