So basically it's merging the results 2 separate queries:   Indexed scan (token-range) intersect foo.flag_index=true  
NO.
It is doing one query, one the secondary index. When it reads the row keys in that index is discards any outside of the token range, 
That query is sent to nodes which have a token range that intersect with the token range you have supplied. 

So if your query token range is included in one Node Token Range, the query will be sent to CL nodes that replicate that token range. 

Cheers
 
-----------------
Aaron Morton
Freelance Cassandra Developer
New Zealand

@aaronmorton

On 31/01/2013, at 3:49 AM, Peter Lin <woolfel@gmail.com> wrote:

I'd also point out, Hector has better support for CQL3 features than
Astyanax. I contributed some stuff to hector back in December, but I
don't have time to apply those changes to astyanax.

I have other contributions in mind for hector, which I hope to work on
later this year.

On Wed, Jan 30, 2013 at 9:45 AM, Edward Capriolo <edlinuxguru@gmail.com> wrote:
Hector has this feature because Hector is awesome sauce, but aystynsnax is
new,sexy, and bogged about by netflix.

So the new cassandra trend to force everyone to use less functional new
stuff is at work here making you wish for something that already exists
elsewhere.


On Wednesday, January 30, 2013, Hiller, Dean <Dean.Hiller@nrel.gov> wrote:
I recall someone doing some work in Astyanax and I don't know if it made
it back in where astyanax would retry at a lower CL level when 2 nodes were
down so things could continue to work which was a VERY VERY cool feature.
You may want to look into thatů.I know at some point, I plan to.

Later,
Dean

From: Edward Capriolo
<edlinuxguru@gmail.com<mailto:edlinuxguru@gmail.com>>
Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>"
<user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
Date: Wednesday, January 30, 2013 7:31 AM
To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>"
<user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
Subject: Re: Node selection when both partition key and secondary index
field constrained?

Any query is going to fail quorum + rf3 + 2 nodes down.

One thing about 2x indexes (both user defined and built in) is that
finding an answer using them requires more nodes to be up then just a single
get or slice.

On Monday, January 28, 2013, Mike Sample
<mike.sample@gmail.com<mailto:mike.sample@gmail.com>> wrote:
Thanks Aaron.   So basically it's merging the results 2 separate queries:
Indexed scan (token-range) intersect foo.flag_index=true     where the
latter query hits the entire cluster as per the secondary index FAQ entry.
Thus the overall query would fail if LOCAL_QUORUM was requested, RF=3 and 2
nodes in a given replication group were down. Darn.  Is there any way of
efficiently getting around this (ie scope the query to just the nodes in the
token range)?




On Mon, Jan 28, 2013 at 11:44 AM, aaron morton
<aaron@thelastpickle.com<mailto:aaron@thelastpickle.com>> wrote:

It uses the index...

cqlsh:dev> tracing on;
Now tracing requests.
cqlsh:dev>
cqlsh:dev>
cqlsh:dev> SELECT id, flag from foo WHERE TOKEN(id) > '-9939393' AND
TOKEN(id) <= '0' AND flag=true;

Tracing session: 128cab90-6982-11e2-8cd1-51eaa232562e

activity                                           | timestamp    |
source    | source_elapsed

----------------------------------------------------+--------------+-----------+----------------
                                execute_cql3_query | 08:36:55,244 |
127.0.0.1 |              0
                                 Parsing statement | 08:36:55,244 |
127.0.0.1 |            600
                                Peparing statement | 08:36:55,245 |
127.0.0.1 |           1408
                     Determining replicas to query | 08:36:55,246 |
127.0.0.1 |           1924
Executing indexed scan for (max(-9939393), max(0)] | 08:36:55,247 |
127.0.0.1 |           2956
Executing single-partition query on foo.flag_index | 08:36:55,247 |
127.0.0.1 |           3192
                      Acquiring sstable references | 08:36:55,247 |
127.0.0.1 |           3220
                         Merging memtable contents | 08:36:55,247 |
127.0.0.1 |           3265
                      Scanned 0 rows and matched 0 | 08:36:55,247 |
127.0.0.1 |           3396
                                  Request complete | 08:36:55,247 |
127.0.0.1 |           3644


It reads from the secondary index and discards keys that are outside of
the token range.

Cheers


-----------------
Aaron Morton
Freelance Cassandra Developer
New Zealand

@aaronmorton
http://www.thelastpickle.com

On 28/01/2013, at 4:24 PM, Mike Sample
<mike.sample@gmail.com<mailto:mike.sample@gmail.com>> wrote:

Does the following FAQ entry hold even when the partion key is also
constrained in the query (by token())?

http://wiki.apache.org/cassandra/SecondaryIndexes:
==
  Q: How does choice of Consistency Level affect cluster availability
when using secondary indexes?

  A: Because secondary indexes are distributed, you must have CL
nodes available for all token ranges in the cluster in order to complete a
query. For example, with RF = 3, when two out of three consecutive nodes in
the ring are unavailable, all secondary index queries at CL = QUORUM will
fail, however secondary index queries at CL = ONE will succeed. This is true
regardless of cluster size."
==

For example:

CREATE TABLE foo (
   id uuid,
   seq_num bigint,
   flag boolean,
   some_other_data blob,
   PRIMARY KEY (id,seq_num)
);

CREATE INDEX flag_index ON foo (flag);

SELECT id, flag from foo WHERE TOKEN(id) > '-9939393' AND TOKEN(id) <=
'0' AND flag=true;

Would the above query with LOCAL_QUORUM succeed given the following?
IE is the token range used first trim node selection?

* the cluster has 18 nodes
* foo is in a keyspace with a replication factor of 3 for that data
center
* 2 nodes in one of the replication groups are down
* the token range in the query is not in the range of the down nodes


Thanks in advance!