Ah, so the secondary indices are really secondary against the primary key. That makes sense.
I'm beginning to see why the whole "date-based table" approach is the only one I've been able to find... thanks for the quick responses, guys! On Mon, Jun 9, 2014 at 2:45 PM, Michal Michalski < michal.michal...@boxever.com> wrote: > 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? >> > >
