@niconiconi You mention that vacuuming the database and similar measures that don't change its contents help significantly. Do you know what are the content-related reasons for the slowdown? (i.e. what grows without bound?)
@niconiconi@mk.absturztau.be @robryk@qoto.org Sounds like it is another case of PostgreSQL query planner biting everyone's butt
@PeterCxy@comfy.social @niconiconi@mk.absturztau.be @robryk@qoto.org :nkoWoozy: yes
@PeterCxy@comfy.social @niconiconi@mk.absturztau.be @robryk@qoto.org floaty seems to be working on something tho that would massively reduce the activities table
@puniko@mk.absturztau.be @niconiconi@mk.absturztau.be @robryk@qoto.org to be fair a large table isn't necessarily the problem. Matrix has huge tables too but it doesn't just blow up out of nowhere.
@PeterCxy@comfy.social @niconiconi@mk.absturztau.be @robryk@qoto.org thing with the activities table is, that nothing gets purged from it afaik (namely remote activities). so it keeps growing and growing. its to such a state in my case, that reindexing the whole database takes several days
@PeterCxy@comfy.social @niconiconi@mk.absturztau.be @robryk@qoto.org and sadly the last couple of times, reindexing didnt even help that much with gaining more speed. idk whats actually the real issue in my case tbh. database might be fine and the issue might reside somewhere else. i have no clue
@PeterCxy@comfy.social @niconiconi@mk.absturztau.be @robryk@qoto.org
:nkocampfiredrink: <- this is me running my stuff
@robryk@qoto.org Pleroma maintains a local record of every post and media it has ever seen from the Fediverse, not unlike other implementations. The database can reach hundreds of gigabytes. From what I've heard, the table structure is not optimal, performance-wise, and query performance eventually collapse.
I have no experience on running any Fedi server and I do not participate in its software development, so I'm not a reliable source. Go ask Pleroma admins for their experience.