entire index row to the node that
> is queried.
>
> -Chris
>
> - Original Message -
> From: "David Leimbach" >
> To: user@cassandra.apache.org
> Sent: Monday, April 2, 2012 8:51:46 AM
> Subject: Re: really bad select performance
>
>
> This is all very
quot;David Leimbach"
To: user@cassandra.apache.org
Sent: Monday, April 2, 2012 8:51:46 AM
Subject: Re: really bad select performance
This is all very hypothetical, but I've been bitten by this before.
Does row_loaded happen to be a binary or boolean value? If so the secondary
index ge
Secondary indexes can generate a lot of random i/o. iostat -x can
confirm if that's your problem.
On Thu, Mar 29, 2012 at 5:52 PM, Chris Hart wrote:
> Hi,
>
> I have the following cluster:
>
> 136112946768375385385349842972707284580
> MountainViewRAC1 Up Normal 1.86 GB 20.0
This is all very hypothetical, but I've been bitten by this before.
Does row_loaded happen to be a binary or boolean value? If so the
secondary index generated by Cassandra will have at most 2 rows, and
they'll be REALLY wide if you have a lot of entries. Since Cassandra
doesn't distribute colum
Is there anything in the logs when you run the queries ?
Try turning the logging up to DEBUG on the node that fails to return and see
what happens. You will see it send messages to other nodes and do work itself.
One thing to note, a query that uses secondary indexes runs on a node for each
t
Hi,
I have the following cluster:
136112946768375385385349842972707284580
MountainViewRAC1Up Normal 1.86 GB 20.00% 0
MountainViewRAC1Up Normal 2.17 GB 33.33%
56713727820156410577229101238628035242
