solrize@lemmy.world
on 19 Aug 2024 02:23
nextcollapse
Fairly lame article but yeah this is something lemmy used to get wrong. I haven’t paid attention to whether it still does.
JadedBlueEyes@programming.dev
on 19 Aug 2024 02:32
nextcollapse
They fixed this in version 0.19 pr #3872 (note that the cursor here is a way of hiding a post ID to continue from, as far as I can see).
Also, lame article? 😖
rimu@piefed.social
on 19 Aug 2024 02:47
nextcollapse
Not lame, I appreciated it and as a result will be implementing ID-based pagination, sometime.
JadedBlueEyes@programming.dev
on 19 Aug 2024 03:04
collapse
Thank you! It’s lovely to hear it was helpful to someone 😊
Max_P@lemmy.max-p.me
on 19 Aug 2024 03:14
nextcollapse
Also, lame article? 😖
It’s pretty short, it could be improved with benchmarks or at least some examples of how that would be implemented efficiently. Maybe a bit of pros and cons, cursor pagination for example doesn’t handle “go directly to page 200” very well. I’ve also seen some interesting hacks to make offset pagination surprisingly fast with a clever subquery.
I mean, for what it’s worth, you calling it “pretty short” is what made me go read the article, because quite frankly, my attention span isn’t long enough to read through an average-length article for a topic like this.
laughterlaughter@lemmy.world
on 20 Aug 2024 11:59
collapse
Now we’re judging articles for quantity instead of quality?
Ah, thanks for linking that PR. The point made in the article is a good and helpful one, as can be seen by the way so many sites get it wrong, including Lemmy in the past. It’s just that it is pretty thin to make a whole article around. It would be a good thing to bring up in an optimization guide that covers more topics.
I would be interested to know if there is substantial cost to keeping cursors open for long periods, while the db is being updated. I think given those labels, it may be preferable to do a new select each time the user requests the next page. But I haven’t benchmarked that.
If you look at how Wikipedia pages through article histories, the labels are timestamps with 1 second resolution.
Here is another article about the same topic, part of the author’s book on SQL performance:
laughterlaughter@lemmy.world
on 20 Aug 2024 11:58
collapse
Who uses “lame” in 2024? It was so pervasive during the Digg times.
Deebster@programming.dev
on 19 Aug 2024 03:14
nextcollapse
In time-based pagination, the suggested fix to lots of data in a selected timespan is:
simply adding a limit to the amount of records returned (potentially via a query parameter) transparently solves it.
This means clients can’t see all the results, unless you add a way to view other pages of data, which is just pagination again. Or is the intended design that clients view either the first x results (the default) or view all results?
The problem with articles like OPs andothers is that they don’t allow custom sorting, which is often a requirement, e.g. interfaces that present the data in a table, where column headers can be clicked to sort.
JadedBlueEyes@programming.dev
on 19 Aug 2024 12:37
collapse
Regarding your first paragraph, this results limit is per page. To get the next page, you take your timestamp of the last item and use it in from_time, or whatever you’ve called it. It’s still a pagination technique.
Regarding custom sorting, some of the techniques in the article can do this, some of them can’t. Obviously timestamp based pagination can’t, however the ID-based pagination that I mentioned can.
jlh@lemmy.jlh.name
on 19 Aug 2024 06:36
nextcollapse
Pretty useful article! I’m pretty sure I’ve seen data shifting happen a few times on Jerboa.
I wonder if uuid7 based pagination solves these issues. Precise enough that you don’t overlap/over fetch data with time based pagination, while still being essentially time based so you have a consistent offset. Definitely important to limit the size if requests, though.
Deebster@programming.dev
on 19 Aug 2024 10:59
collapse
Probably not; I’d expect the places where you need something like UUIDv7 (large, eventually-consistent systems) to not be entirely suitable because you can have records added out of sequence. You’d have to add a received-at field - but in that case you may as well just use a standard incrementing ID as your primary key.
MonkderVierte@lemmy.ml
on 19 Aug 2024 08:40
collapse
lazily loading notifications
…What?
JadedBlueEyes@programming.dev
on 19 Aug 2024 12:26
collapse
This whole article was sprung from a discussion of exactly that case, because users often simply don’t delete notifications. It’s very common for users to have years of undismissed notifications stacked up under the notification bell, and it’s not a good experience to load them all at once.
MonkderVierte@lemmy.ml
on 19 Aug 2024 12:37
collapse
Ah, like smartphone/Windows notifications, not webpage popups? Yeah, always wonder how my dad doesn’t miss everything, despite always having 20+ notifications.
JadedBlueEyes@programming.dev
on 19 Aug 2024 12:40
nextcollapse
Yeah, or even the inbox in lemmy. It’s a surprisingly common thing.
GetOffMyLan@programming.dev
on 20 Aug 2024 09:14
collapse
Yes when they said notifications they meant notifications hehe
threaded - newest
Fairly lame article but yeah this is something lemmy used to get wrong. I haven’t paid attention to whether it still does.
They fixed this in version 0.19 pr #3872 (note that the cursor here is a way of hiding a post ID to continue from, as far as I can see).
Also, lame article? 😖
Not lame, I appreciated it and as a result will be implementing ID-based pagination, sometime.
Thank you! It’s lovely to hear it was helpful to someone 😊
It’s pretty short, it could be improved with benchmarks or at least some examples of how that would be implemented efficiently. Maybe a bit of pros and cons, cursor pagination for example doesn’t handle “go directly to page 200” very well. I’ve also seen some interesting hacks to make offset pagination surprisingly fast with a clever subquery.
I wouldn’t call it lame though.
I mean, for what it’s worth, you calling it “pretty short” is what made me go read the article, because quite frankly, my attention span isn’t long enough to read through an average-length article for a topic like this.
Now we’re judging articles for quantity instead of quality?
Ah, thanks for linking that PR. The point made in the article is a good and helpful one, as can be seen by the way so many sites get it wrong, including Lemmy in the past. It’s just that it is pretty thin to make a whole article around. It would be a good thing to bring up in an optimization guide that covers more topics.
I would be interested to know if there is substantial cost to keeping cursors open for long periods, while the db is being updated. I think given those labels, it may be preferable to do a new select each time the user requests the next page. But I haven’t benchmarked that.
If you look at how Wikipedia pages through article histories, the labels are timestamps with 1 second resolution.
Here is another article about the same topic, part of the author’s book on SQL performance:
use-the-index-luke.com/sql/…/fetch-next-page
Who uses “lame” in 2024? It was so pervasive during the Digg times.
In time-based pagination, the suggested fix to lots of data in a selected timespan is:
This means clients can’t see all the results, unless you add a way to view other pages of data, which is just pagination again. Or is the intended design that clients view either the first x results (the default) or view all results?
The problem with articles like OPs and others is that they don’t allow custom sorting, which is often a requirement, e.g. interfaces that present the data in a table, where column headers can be clicked to sort.
Regarding your first paragraph, this results limit is per page. To get the next page, you take your timestamp of the last item and use it in
from_time, or whatever you’ve called it. It’s still a pagination technique.Regarding custom sorting, some of the techniques in the article can do this, some of them can’t. Obviously timestamp based pagination can’t, however the ID-based pagination that I mentioned can.
Pretty useful article! I’m pretty sure I’ve seen data shifting happen a few times on Jerboa.
I wonder if uuid7 based pagination solves these issues. Precise enough that you don’t overlap/over fetch data with time based pagination, while still being essentially time based so you have a consistent offset. Definitely important to limit the size if requests, though.
Probably not; I’d expect the places where you need something like UUIDv7 (large, eventually-consistent systems) to not be entirely suitable because you can have records added out of sequence. You’d have to add a received-at field - but in that case you may as well just use a standard incrementing ID as your primary key.
…What?
This whole article was sprung from a discussion of exactly that case, because users often simply don’t delete notifications. It’s very common for users to have years of undismissed notifications stacked up under the notification bell, and it’s not a good experience to load them all at once.
Ah, like smartphone/Windows notifications, not webpage popups? Yeah, always wonder how my dad doesn’t miss everything, despite always having 20+ notifications.
Yeah, or even the inbox in lemmy. It’s a surprisingly common thing.
Yes when they said notifications they meant notifications hehe