Secondary indexes internally are just CFs that map the indexed value to a row key which that value belongs to, so you can only query these indexes using "=", not ">", ">=" etc.
However, your query does not require index *IF* you provide a row key - you can use "<" or ">" like you did for the date column, as long as you refer to a single row. However, if you don't provide it, it's not going to work. M. Kind regards, MichaĆ Michalski, michal.michal...@boxever.com On 9 June 2014 21:18, Redmumba <redmu...@gmail.com> wrote: > I have a table with a timestamp column on it; however, when I try to query > based on it, it fails saying that I must use ALLOW FILTERING--which to me, > means its not using the secondary index. Table definition is (snipping out > irrelevant parts)... > > CREATE TABLE audit ( >> id bigint, >> date timestamp, >> ... >> PRIMARY KEY (id, date) >> ); >> CREATE INDEX date_idx ON audit (date); >> > > There are other fields, but they are not relevant to this example. The > date is part of the primary key, and I have a secondary index on it. When > I run a SELECT against it, I get an error: > > cqlsh> SELECT * FROM asinauditing.asinaudit WHERE date < '2014-05-01'; >> Bad Request: Cannot execute this query as it might involve data filtering >> and thus may have unpredictable performance. If you want to execute this >> query despite the performance unpredictability, use ALLOW FILTERING >> cqlsh> SELECT * FROM asinauditing.asinaudit WHERE date < '2014-05-01' >> ALLOW FILTERING; >> Request did not complete within rpc_timeout. >> > > How can I force it to use the index? I've seen rebuild_index tasks > running, but can I verify the "health" of the index? >