RocketDerp

> found a great way to optimize the existing queries: to do a subselect _before_ the rest of the heavy joins. #2994 I personally pulled active queries out of the...

Given the massive performance problems people are having, pg_stat_statements and sharing data out of Beehaw, Lemmy.ml, Lemmy.world several weeks ago would have really saved all this time having to run...

I also think that person-to-person blocking and alternate-language filtering should be considered something to remove from the back-end, API. It means that the database has to do the filtering for...

> And this is fine with negative joins. PostgreSQL is really amazing here on the generated plans. I wouldn't worry about this, as, like @dessalines wrote, that is what the...

The logs of the big servers hold all the secrets of just how frequently code is crashing/exceptions internally. The lemmy-ui doesn't even properly parse "timeout" and say to end-users: "the...

> Can we please limit this discussion to SQL/Database stuff? If it isn't the SQL faulting, what is it? Are you guys literally not understanding that the SQL backed is...

> that can happen on everything, and is clearly not SQL related. "clearly", no it isn't "clear" n any way shape or form, and I assure you that I know...

Who here has gone out of their way to publish an entire application dedicated to looking at PostgreSQL performance problems within Lemmy? Please stand up!  "Clear" and "clearly" do...

As I mentioned in this issue comments on June 26, pg_stat_statements data out of the big servers (called out by name June 22, https://lemm.ee/comment/350801) - well finally one of them...

> Also @RocketDerp be respectful, or we will block you from this repo. I have autism, and I do not grasp what you think I am doing wrong socially that...