Hi Tom, There is an outstanding JIRA issue to directly support what you want (with a patch even!) but no work on it recently: <https://issues.apache.org/jira/browse/SOLR-6635>. If you’re so inclined, please pitch in: bring the patch up-to-date, test it, contribute improvements, etc.
-- Steve www.lucidworks.com > On Mar 22, 2016, at 10:27 AM, Tom Evans <tevans...@googlemail.com> wrote: > > 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
