Many thx for the explanation Aaron.
On Wednesday, July 4, 2012, aaron morton wrote:
> > select my_cf where columnA = a and columnB = b and columnC = c and
> columnD = d
> Cassandra will only use one equality clause to select the candidate rows.
> The other clauses are applied to the rows using t
> select my_cf where columnA = a and columnB = b and columnC = c and columnD = d
Cassandra will only use one equality clause to select the candidate rows. The
other clauses are applied to the rows using that first clause.
The clause to use to select candidate rows is based on statistics that est
Hi all
We have 4 indexed columns; all configured in UT8Type even if one columns is
a date and the other an integer).
1/ the read query we run can have up to 4 criteria
*select my_cf where columnA = a and columnB = b and columnC = c and columnD
= d*
This query, is fast (<500ms) up to 3 criterias
>
>> Anyone know if secondary index performance should be in the 100-500 ms
>> range. That's what we're seeing right now when doing lookups on a single
>> value. We've increased keys_cached and rows_cached to 100% for that column
>> family and assu
On Sun, Jul 3, 2011 at 5:12 PM, Jeremy Hanna wrote:
> Trying some other stuff with tools mentioned here:
> http://spyced.blogspot.com/2010/01/linux-performance-basics.html but not
> seeing anything particularly disk bound, though await (from iostat -x) seems
> high on one of the devices.
Are y
On Jul 3, 2011, at 4:29 PM, Jeremy Hanna wrote:
> Anyone know if secondary index performance should be in the 100-500 ms range.
> That's what we're seeing right now when doing lookups on a single value.
> We've increased keys_cached and rows_cached to 100% for t
Anyone know if secondary index performance should be in the 100-500 ms range.
That's what we're seeing right now when doing lookups on a single value. We've
increased keys_cached and rows_cached to 100% for that column family and assume
that the secondary index gets the same at
