mirabilos

OK, here’s it now in slow: ``` psql (13.11 (Debian 13.11-0+deb11u1)) Type "help" for help. gotosocial=# EXPLAIN ANALYZE SELECT count(*) FROM "statuses" AS "status" WHERE ("status"."account_id" = '…'); QUERY PLAN...

tobi dixit: >Ah thanks for catching it again! I still feel like 1GiB should be more >than enough, so I reckon we've gotta do some creative thinking about >performance improvements...

Ezra Barrow dixit: > Execution Time: 19804.337 ms Huh, that’s impressive. I assume you VACUUM ANALYZE regularily. What saved my instance was a move to a differently spec’d VM. It’s...

tobi dixit: >It's berserk to me that postgres struggles so hard with this when >sqlite handles it no problem. Very frustrating. Different base design choices. The problem here is that...

Ezra Barrow dixit: >running a `VACUUM ANALYZE statuses;` does seem to have alleviated the >issue enough to be usable. timeline and notification requests generally >return in reasonable time now. no...

kim dixit: >the PR i pushed should help, but beyond a certain point it feels like >we're just providing workarounds for suboptimal hosting conditions for >a gotosocial postgres setup. due...

tobi dixit: >But of course that doesn't necessarily solve the Postgres problem; >running ANALYZE regularly on Postgres is something that DB operators >need to schedule themselves, I believe. I think...

I solved this for my VM by creating a separate filesystem for GtS storage. This also helps with backups (with `--one-filesystem`): they are backed up together, but to different restic...

hikari_no_yume dixit: >@mirabilos I don't think separate storage for the media cache really >@solves the problem? It's already in its own directory and I could >@easily put it in its...

hikari_no_yume dixit: >It seems I have the same problem with the newer version I'm using now. Did you reduce media-remote-cache-days in config.yaml already? >I really need to write that cron...