Hello Ian
Secondary index performs poorly with inequalities (<, ≤, >, ≥). Indeed
inequalities forces the server to scan all the cluster to find the
requested range, which is clearly not optimal. That's the reason why you
need to add "ALLOW FILTERING" for the query to be accepted.
"ALLOW FILTERING" means "beware of what you're doing, we C* developers do
not give any guarantee about performance of such query".
As Robert Coli used to say on this list, ALLOW FILTERING is synonym to
PROBABLY TIMEOUT :D
On Wed, Aug 13, 2014 at 2:56 PM, Ian Rose <ianr...@fullstory.com> wrote:
> Confusingly, it appears to be the presence of an index on int_val that is
> causing this timeout. If I drop that index (leaving only the index on
> foo_name) the query works just fine.
>
>
> On Tue, Aug 12, 2014 at 10:25 PM, Ian Rose <ianr...@fullstory.com> wrote:
>
>> Hi -
>>
>> I am currently running a single Cassandra node on my local dev machine.
>> Here is my (test) schema (which is meaningless, I created it just to
>> demonstrate the issue I am running into):
>>
>> CREATE TABLE foo (
>> foo_name ascii,
>> foo_shard bigint,
>> int_val bigint,
>> PRIMARY KEY ((foo_name, foo_shard))
>> ) WITH read_repair_chance=0.1;
>>
>> CREATE INDEX ON foo (int_val);
>> CREATE INDEX ON foo (foo_name);
>>
>> I have inserted just a single row into this table:
>> insert into foo(foo_name, foo_shard, int_val) values('dave', 27, 100);
>>
>> This query works fine:
>> select * from foo where foo_name='dave';
>>
>> But when I run this query, I get an RPC timeout:
>> select * from foo where foo_name='dave' and int_val > 0 allow filtering;
>>
>> With tracing enabled, here is the trace output:
>> http://pastebin.com/raw.php?i=6XMEVUcQ
>>
>> (In short, everything looks fine to my untrained eye until 10s elapsed,
>> at which time the following event is logged: "Timed out; received 0 of 1
>> responses for range 257 of 257")
>>
>> Can anyone help interpret this error?
>>
>> Many thanks!
>> Ian
>>
>>
>
