Hi all With Solr 5.5.0, we're trying to improve our paging performance. When we are delivering results using infinite scrolling, cursorMark is perfectly fine - one page is followed by the next. However, we also offer traditional paging of results, and this is where it gets a little tricky.
Say we have 10 results per page, and a user wants to jump from page 1 to page 20, and then wants to view page 21, there doesn't seem to be a simple way to get the nextCursorMark. We can make an inefficient request for page 20 (start=190, rows=10), but we cannot give that request a cursorMark=* as it contains start=190. Consequently, if the user clicks to page 21, we have to continue along using start=200, as we have no cursorMark. The only way I can see to get a cursorMark at that point is to omit the start=200, and instead say rows=210, and ignore the first 200 results on the client side. Obviously, this gets more and more inefficient the deeper we page - I know that internally to Solr, using start=200&rows=10 has to do the same work as rows=210, but less data is sent over the wire to the client. As I understand it, the cursorMark is a hash of the sort values of the last document returned, so I don't really see why it is forbidden to specify start=190&rows=10&cursorMark=* - why is it not possible to calculate the nextCursorMark from the last document returned? I was also thinking a possible temporary workaround would be to request start=190&rows=10, note the last document returned, and then make a subsequent query for q=id:"<last doc id>"&rows=1&cursorMark=*. This seems to work, but means an extra Solr query for no real reason. Is there any other problem to doing this? Is there some other simple trick I am missing that we can use to get both the page of results we want and a nextCursorMark for the subsequent page? Cheers Tom
