His site is a great resource for anyone wanting to take a deeper dive on SQL performance:
https://use-the-index-luke.com/sql/partial-results/fetch-nex...
His site is a great resource for anyone wanting to take a deeper dive on SQL performance:
https://use-the-index-luke.com/sql/partial-results/fetch-nex...
https://old.reddit.com/?count=25&after=t3_wtpvdp
I noticed Reddit's pagination has that "after" parameter, which points to the last post on the current page.
It glitches out if the last item is deleted by moderators, but otherwise it works smoothly.
The only solution I can think of for that is to track which individual posts have been shown to which users, which is quite a lot of work to do.
https://en.wikipedia.org/w/index.php?title=Category:Living_p...
No need for row value syntax and it works with MS SQL Server
> If your column is fairly uniformly distributed you can guess the index for any arbitrary page.
I don't think that'll work in a multi-tenancy situation with complex filters.
It definitely isn’t in the users’ best interest to have any method of scrolling through a lot of records.
Unless you can guarantee your data is static, or that the sorting order cannot be mutated and only append later values, the concept of what data belongs in which page could be changing every millisecond.
> As we saw, plain keyset pagination offers no facility to jump a certain percentage into the results except through client guesswork. However the PostgreSQL statistics collector maintains per-column histograms of value distribution. We can use these estimates in conjunction with limits and small offsets to get fast random-access pagination through a hybrid approach.