phiresky

what's the time frame the screenshot data is from? purely after the upgrade? how long did it run? The second query with 161s total time and 15k calls is the...

One more thing, after a 30min+ downtime the instance will get hammered by incoming federation queries trying to catch the instance up to the current state of the network. Since...

Yeah, it's a bit harder to check incoming federation state which is the important part here. Outgoing federation will be idle after downtime. A query like `select * from federation_queue_state...

> So we still have to investigate which commit is causing the slowness. I wouldn't necessarily assume that a code change is the cause, it might just be lemmy in...

i'm still not convinced it's related to any actual change rather than just a combination of the migration rewriting a table, destroying the in-memory page cache, and then the downtime...

That's weird. I don't see anything suspicious in that commit... How did you narrow it down? As far as I know, the max length of strings `varchar(x)` vs `text` is...

Sorry, I missed your above comment. > if lemmy.ml is down for half an hour then I believe it would take at least half an hour more for other instances...

Mh. sounds like pretty clean testing. I'd still be very surprised if the actual issue is the varchar(x) change though. One last ditch suggestion: It could be the missing statistics....

if it still stays slow then really the only thing I think it can be is missing stats, `analyze post`

Not convinced this would be a good idea. The current system works perfectly fine, a single additional O(1) query is basically irrelevant compared to the cost of a post view...