"It will merge requests to neighboring ranges when the same node is a replica for both of them. Without vnodes, this usually results in all ranges for a node being merged. With vnodes, merging still happens, but not all ranges can be merged." -->
But does it implies that with vnodes, there are actually "extra work" to do for scanning indices ? If yes, is this "extra load" rather I/O bound or CPU bound ? On Fri, Sep 19, 2014 at 11:10 PM, Tyler Hobbs <ty...@datastax.com> wrote: > > On Fri, Sep 19, 2014 at 12:41 PM, Jay Patel <pateljay3...@gmail.com> > wrote: > >> >> Btw, there is no data in the table. Table is empty. Query is fired on the >> empty table. >> > > This is actually the worst case for secondary index lookups. > > >> >> From the tracing ouput, I don't understand why it's doing multiple scans >> on one node. With non-vnode, there is only one scan per node & same query >> works fine. >> >> If you look at the output1.txt attached earlier, coordinator is firing >> index scan on a given node (for example, 192.168.51.22 in the below snippet >> from output1.txt) multiple times for different token ranges. Why can't it >> fire only one time? With non-vnode, it's only one time & query comes back >> very fast. > > > It will merge requests to neighboring ranges when the same node is a > replica for both of them. Without vnodes, this usually results in all > ranges for a node being merged. With vnodes, merging still happens, but > not all ranges can be merged. > > > -- > Tyler Hobbs > DataStax <http://datastax.com/> >
