4
submitted 1 year ago by [email protected] to c/[email protected]
you are viewing a single comment's thread
view the rest of the comments
[-] [email protected] 1 points 1 year ago

i’d hope the query planner can still do something reasonable.

PostgreSQL specifically guards against queries with more than 8 joins... and Lemmy plows right past that.

[-] [email protected] 1 points 1 year ago

What can I say, that sounds suspicious both from the PG side (complex queries with lots of joins are sometimes useful, such as for reporting) and on the Lemmy side (executing such queries in response to routine web requests is a pretty bad smell). It's still early days so this seems like a better time to re-examine the schema and migrate if necessary, than after waiting until there's a ton more data and activity.

[-] [email protected] 1 points 1 year ago* (last edited 1 year ago)

It’s still early days

Lemmy has been on GitHub since February 2019, over four years. It isn't new at all. Several instances go way back.

The answer is: ORM.

[-] [email protected] 2 points 1 year ago

I don't mean the code is new, I mean the user base and data corpus are small compared to what we are hoping for. You're probably right about the ORM. :/

this post was submitted on 17 Aug 2023
4 points (100.0% liked)

Lemmy Server Performance

422 readers
1 users here now

Lemmy Server Performance

lemmy_server uses the Diesel ORM that automatically generates SQL statements. There are serious performance problems in June and July 2023 preventing Lemmy from scaling. Topics include caching, PostgreSQL extensions for troubleshooting, Client/Server Code/SQL Data/server operator apps/sever operator API (performance and storage monitoring), etc.

founded 1 year ago
MODERATORS