'bundle exec rake db:migrate' taking a long time due to calendar migration

Support Self-hosting
16 
ystemd+  7660  0.0  0.3 352060 28284 ?        S    22:31   0:00 /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
systemd+  7667  0.0  0.1 352588  9628 ?        Ss   22:31   0:00 postgres: 13/main: checkpointer 
systemd+  7668  0.3  0.9 352060 78796 ?        Ss   22:31   0:03 postgres: 13/main: background writer 
systemd+  7669  0.0  0.1 352060 13696 ?        Ss   22:31   0:00 postgres: 13/main: walwriter 
systemd+  7670  0.0  0.1 352728 11892 ?        Ss   22:31   0:00 postgres: 13/main: autovacuum launcher 
systemd+  7671  0.0  0.0  67996  5320 ?        Ss   22:31   0:00 postgres: 13/main: stats collector 
systemd+  7672  0.0  0.0 352612  6640 ?        Ss   22:31   0:00 postgres: 13/main: logical replication launcher 
systemd+ 10900 82.0  3.8 487164 317728 ?       Rs   22:33  10:42 postgres: 13/main: discourse discourse [local] DELETE
systemd+ 10901  0.0  0.1 353432 13804 ?        Ss   22:33   0:00 postgres: 13/main: discourse discourse [local] idle

htop shows that the discourse [local] delete is what’s eating 100% cpu. The droplet has 8GB of RAM, and right now <1GB is in use (not counting buffers).

The OS is out of date, but this seems very strange to me. There’s plenty of RAM and disk, and that postgres delete task has been running for >12 minutes. There are less than 600K posts and <4K users, so the database isn’t huge. Oh. Wait. the postgres_data directory is 28GB.

I ran a VACUUM VERBOSE ANALYZE;.

I did this:

discourse=# SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter; 
 checkpoints_timed | checkpoints_req 
-------------------+-----------------
                 6 |              20

I’m now trying to reindex concurrently. Perhaps the vacuum and reindex will help.