Is the post_read table where info on what a user has or has not read is stored? I am wondering now if a huge db like that is the cost of implementing features like marking unread comments or posts.
…not that I have a great idea of how to do that since I don’t know js at all, but db size is something to keep in mind when the intention is to have federated instances, each with their own infrastructure.
yes, post_read marks which posts a user has marked as read. it links post ids with user ids and adds a timestamp on top to allow for sorting.
edit:
for comments, lemmy only stores the number of read comments per post, which is what goes into person_post_aggregates. this is a tradeoff, it has some limitations, e.g. when comments are deleted or removed, which affects the total count. as there is also a timestamp attached it might be possible to use that in combination with comment creation times, though this would likely impact query performance quite a bit more.
The scale of LW is impressive as always.
Is the
post_readtable where info on what a user has or has not read is stored? I am wondering now if a huge db like that is the cost of implementing features like marking unread comments or posts.…not that I have a great idea of how to do that since I don’t know js at all, but db size is something to keep in mind when the intention is to have federated instances, each with their own infrastructure.
yes,
post_readmarks which posts a user has marked as read. it links post ids with user ids and adds a timestamp on top to allow for sorting.edit:
for comments, lemmy only stores the number of read comments per post, which is what goes into
person_post_aggregates. this is a tradeoff, it has some limitations, e.g. when comments are deleted or removed, which affects the total count. as there is also a timestamp attached it might be possible to use that in combination with comment creation times, though this would likely impact query performance quite a bit more.