See, I noticed this stuff reading through the Lemmy source code, but I assumed the authors just were on another level of database use than me. Is this actually just a mess? How exactly is it bad, beyond being opaque?
This doesn’t look like anything out of the ordinary in a real-world application to me. We have way more complex queries in our service, even though ours are hand crafted.
One thing we did notice though is that sometimes, it’s faster to just query the whole dataset and do the complex filtering in Rust. As soon as you hit the seq scan heuristic in PostgreSQL, there’s nothing to be gained from doing it in SQL.
It isn’t the complexity that is the problem. It is the open-ended nature. It lacks any WHERE clause that specifies which posts to get. It just kicks off join after join without restricting what it is looking for. It relies on the “LIMIT 50” that Lemmy restricts post listings too. Which worked OK in March 2023 when Lemmy was over 4 years old and still had very tiny amounts of data in all these tables that it joins, but once even a modest amount of data got point in the open-ended nature of the WHERE clause kept making it slower and slower as more and more content.
Lemmy 0.18.4 listing posts, frequently via ORM Diesel:
That is with hand-optimized person_id = $1, which the Rust code does not do.
I cry just reading that…
See, I noticed this stuff reading through the Lemmy source code, but I assumed the authors just were on another level of database use than me. Is this actually just a mess? How exactly is it bad, beyond being opaque?
serous problems with scalability, it works fine if there is little data in the system.
Huh. I guess I’ll have to learn a bit more.
This is effectively a binary blob to me lol
This doesn’t look like anything out of the ordinary in a real-world application to me. We have way more complex queries in our service, even though ours are hand crafted.
One thing we did notice though is that sometimes, it’s faster to just query the whole dataset and do the complex filtering in Rust. As soon as you hit the seq scan heuristic in PostgreSQL, there’s nothing to be gained from doing it in SQL.
It isn’t the complexity that is the problem. It is the open-ended nature. It lacks any WHERE clause that specifies which posts to get. It just kicks off join after join without restricting what it is looking for. It relies on the “LIMIT 50” that Lemmy restricts post listings too. Which worked OK in March 2023 when Lemmy was over 4 years old and still had very tiny amounts of data in all these tables that it joins, but once even a modest amount of data got point in the open-ended nature of the WHERE clause kept making it slower and slower as more and more content.