On Wed, Mar 23, 2016 at 12:21 PM, Vanlerberghe, Luc <luc.vanlerber...@bvdinfo.com> wrote: > I worked on something similar a couple of years ago, but didn’t continue work > on it in the end. > > I've included the text of my original mail. > If you're interested, I could try to find the sources I was working on at the > time > > Luc >
Thanks both Luc and Steve. I'm not sure if we will have time to deploy patched versions of things to production - time is always the enemy :( , and we're not a Java shop so there is non trivial time investment in just building replacement jars, let alone getting that integrated in to our RPMs - but I'll definitely try it out on my dev server. The change seems excessively complex imo, but maybe I'm not seeing the use cases for skip. To my mind, calculating a nextCursorMark is cheap and only relies on having a strict sort ordering, which is also cheap to check. If that condition is met, you should get a nextCursorMark in your response regardless of whether you specified a cursorMark in the request, to allow you to efficiently get the next page. This would still leave slightly pathological performance if you skip to page N, and then iterate back to page 0, which Luc's idea of a previousCursorMark can solve. cursorMark is easy to implement, you can ignore docs which sort lower than that mark. Can you do similar with previousCursorMark?, as would it not require to keep a buffer of rows documents, and stop when a document which sorts higher than the supplied mark appears. Seems more complex, but maybe I'm not understanding the internals correctly. Fortunately for us, 90% of our users prefer infinite scroll, and 97% of them never go beyond page 3. Cheers Tom
