No fellow human of course I am not an Artificial Intelligence. I have no idea what would make you think I was.

I guessing you just deleted to numbers and went with the first option like I did 😂

Did you find a solution. The above comment with the database query should work. You can access the docker container where the database is running with docker exec -it instancedomain_postgres_1 busybox /bin/sh and then run psql -U databaseuser which by default is 'lemmy'.

Check docker ps to know the exact name of the postgres container which in your case likely is lemmytalungorg_postgres_1

Sure. Triggers are normally a good idea as they make sure that data is consistent. Like when you delete a user, a trigger will run to also decrease the number of users by one. But since they run for every row, they can certainly impact performance. Foreign key checks are also implementet as triggers so if your missing an index and the db has to crawl through huge tables of data for every delete (I suspect this was the cause of slowdown during DELETE), that too will affect performance.

While I don't do it often, here is the superuser command I use in psql to disable the triggers before doing any other commands:

SET session_replication_role TO replica;

This is something postgresq uses internally when applying replication data, as it assumes all the data is correct and valid and don't fire any of the triggers or rules that would normally apply when modifying data. As you can see from the name, this is a session setting. If you quit the db session, everything goes back to normal so no data is changed and you don't run the risk of forgetting to change it back when your done.

If you do want to go back to normal operation during the same session for some reason, this gets you back to the default:

SET session_replication_role TO origin;

And thank you for the helpful post about the bot problem in the first place.