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

Reply via email to