> On 19 Nov 2014, at 4:44 am, Tyler Hobbs <ty...@datastax.com> wrote: > >> On Tue, Nov 18, 2014 at 4:46 AM, Jacob Rhoden <jacob.rho...@me.com> wrote: >> >> I was going to report a bug, but first figured I should check its not >> “working as expected”. Is it just me or is it wrong that the following >> query needs to talk to both nodes to build a response to this query? > > It seems to be working as expected to me, unless I'm missing something.
If there are two nodes and RF=2, a simple data lookup on a very small table will only need to talk to one node if you put in a (fake/pointless) partition key, but two nodes if you don't. The impact is that if you want 1ms query time on a 50 row table you must use a partition key, otherwise you get 250ms query time. >> Why is this a bug? It seems that this behaviour of needing a response to >> both nodes only exists if you don’t query with a clustering key, or a key >> when RF=2. However you can change this behaviour, by, for example, changing >> the table from “primary key (uuid)” to “primary key ((a), uuid)” where the >> value of a always equals “a” ( so you can query 'where a=“a”’), at which >> point, cassandra decides it only needs results from one node. > > Can you clarify what you mean? It sounds like you're saying "if I specify > a partition key, it only needs to query one node", which is also expected > behavior (assuming a consistency level of ONE). It's my understanding from the documentation that consistency level one (which I am using) is about write consistency, not read consistency. Actually if I change it in cqlsh, cqlsh refuses to run the query. > By the way, this type of question is better suited for the user mailing > list than the dev Ok thanks, I'll file it as a bug request with more details. Thanks!
