starman@programming.dev to Programming@programming.devEnglish · edit-211 months agoWhy You Shouldn’t Use OFFSET and LIMIT For Your Paginationivopereira.netexternal-linkmessage-square18fedilinkarrow-up114arrow-down117file-text
arrow-up1-3arrow-down1external-linkWhy You Shouldn’t Use OFFSET and LIMIT For Your Paginationivopereira.netstarman@programming.dev to Programming@programming.devEnglish · edit-211 months agomessage-square18fedilinkfile-text
If you are wondering why lemmy is moving away from offset pagination since 0.19, here is a nice article about it
minus-squareWilliam@lemmy.worldlinkfedilinkarrow-up10·11 months agohttps://ivopereira.net/efficient-pagination-dont-use-offset-limit This seems to be the same article. I have my doubts about the technique, but it could be useful in certain controlled situations.
minus-squareMax-P@lemmy.max-p.melinkfedilinkarrow-up5·11 months agoLemmy just implemented it for 0.19 and it makes a big difference on heavier queries like Scaled homepage. It also has the advantage of your pagination not getting screwy if new content has been added between page 2 and 3 queries.
minus-squareMegaMacSlice@programming.devlinkfedilinkarrow-up2·11 months agoI was going to recommend looking at https://www.elastic.co/guide/en/elasticsearch/reference/current/paginate-search-results.html#scroll-search-results - but it looks like that method is now not advised- but if you read up above it it looks like there’s a search_after/PIT method described which sounds similar to the article. This is all to say - I don’t think this is a one-off concept - it’s been around for a bit.
minus-squarevzq@lemmy.blahaj.zonelinkfedilinkarrow-up1·11 months agoIt depends on what you want to do and how you want it to behave if data is inserted or deleted. “Ten items after the last one I’ve seen” is another thing than “items 30 to 39”.
minus-squareSpaceNoodle@lemmy.worldlinkfedilinkarrow-up1·11 months agoThanks! Agreed, it’s a very limited usecase.
minus-squarevzq@lemmy.blahaj.zonelinkfedilinkarrow-up1·11 months ago I have my doubts about the technique, but it could be useful in certain controlled situations This is completely uncontroversial advice and has been for 30 years. What are your doubts exactly? I’d go further: if you see a query that uses “offset” on a non-trivial production DB something is very, very wrong. Of course, the trick is that you need to make sure you have indexes for all sort orders you need to display, but that’s obvious.
https://ivopereira.net/efficient-pagination-dont-use-offset-limit
This seems to be the same article.
I have my doubts about the technique, but it could be useful in certain controlled situations.
Lemmy just implemented it for 0.19 and it makes a big difference on heavier queries like Scaled homepage.
It also has the advantage of your pagination not getting screwy if new content has been added between page 2 and 3 queries.
I was going to recommend looking at https://www.elastic.co/guide/en/elasticsearch/reference/current/paginate-search-results.html#scroll-search-results - but it looks like that method is now not advised- but if you read up above it it looks like there’s a search_after/PIT method described which sounds similar to the article.
This is all to say - I don’t think this is a one-off concept - it’s been around for a bit.
It depends on what you want to do and how you want it to behave if data is inserted or deleted. “Ten items after the last one I’ve seen” is another thing than “items 30 to 39”.
Thanks! Agreed, it’s a very limited usecase.
This is completely uncontroversial advice and has been for 30 years. What are your doubts exactly?
I’d go further: if you see a query that uses “offset” on a non-trivial production DB something is very, very wrong.
Of course, the trick is that you need to make sure you have indexes for all sort orders you need to display, but that’s obvious.