'bundle exec rake db:migrate' demorando muito devido à migração de calendário

Suporte Instalação
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

O htop mostra que o discourse [local] delete é o que está consumindo 100% da CPU. O droplet tem 8GB de RAM, e no momento <1GB está em uso (sem contar buffers).

O SO está desatualizado, mas isso me parece muito estranho. Há RAM e disco de sobra, e essa tarefa de delete do postgres está rodando há mais de 12 minutos. Há menos de 600K posts e <4K usuários, então o banco de dados não é enorme. Ah. Espere. O diretório postgres_data tem 28GB.

Executei um VACUUM VERBOSE ANALYZE;.

Eu fiz isso:

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

Estou agora tentando reindexar concorrentemente. Talvez o vacuum e o reindex ajudem.