That's only a small part of the problem.  A larger issue is that what follows the index read is basically a multiget within that node, which generates a lot of non-sequential I/O.  The second issue is that nodes are queried sequentially to get more result rows until the requested row count has been reached.  So, if each node only has a handful of matching rows, you'll end up querying every node in the cluster (more or less) to answer the query.

On Tue, Jul 31, 2012 at 8:44 PM, Arya Goudarzi <goudarzi@gmail.com> wrote:
I know that secondary indexes are stored
to local column families on each node. Previously where the default
cache key value was 200,000 rows, and you couldn't really tune the
local index column family, that posed a limitation on low cardinality
of the possible values of the secondary index column. However, in
Cassandra 1.1.2, I don't see the option of tuning cache per row count
any more and it is solely memory based. I wonder if this eliminates he
previous limitations with secondary indexes.



--
Tyler Hobbs
DataStax