Re: Efficient Paging Option in Wide Rows

I tend to agree with Carlos. Having multiple row keys and parallelizing your queries will tend to result in faster responses. Keeping positions relatively small will also help your cluster to manage your data more efficiently also resulting in better performance. One thing I would recommend is

Re: Efficient Paging Option in Wide Rows

Hi Anuj, That's a very good question and I'd like to hear an answer from anyone who can give a detailed answer, but in the mean time I'll try to give my two cents. First of all I think I'd rather split all the values into different partition keys for two reasons: 1.- If you're sure you're

Re: Efficient Paging Option in Wide Rows

Hi, Can anyone take this question? ThanksAnuj Sent from Yahoo Mail on Android On Sat, 23 Apr, 2016 at 2:30 PM, Anuj Wadehra wrote: I think I complicated the question..so I am trying to put the question crisply.. We have a table defined with clustering key/column.

Re: Efficient Paging Option in Wide Rows

I think I complicated the question..so I am trying to put the question crisply.. We have a table defined with clustering key/column. We have  5 different clustering key values.  If we want to fetch all 5 rowd,Which query option would be faster and why? 1. Given a single primary

Efficient Paging Option in Wide Rows

Hi, I have a wide row index table so that I can fetch all row keys corresponding to a column value.  Row of index_table will look like: ColValue1:bucket1 >> rowkey1, rowkey2.. rowkeyn..ColValue1:bucketn>> rowkey1, rowkey2.. rowkeyn We will have buckets to avoid hotspots. Row keys of main