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

Suporte Instalação
32 
      DELETE
        FROM calendar_events ce
      WHERE
        ce.id IN (SELECT DISTINCT(ce3.id) FROM calendar_events ce2
                  LEFT JOIN calendar_events ce3 ON ce3.user_id = ce2.user_id AND ce3.description = ce2.description
                  WHERE ce2.start_date >= (ce3.start_date - INTERVAL '1 days')
                    AND ce2.start_date <= (ce3.start_date + INTERVAL '1 days')
                    AND ce2.timezone IS NOT NULL
                    AND ce3.timezone IS NULL
                    AND ce3.id != ce2.id
                    AND ce2.post_id IS NULL
                    AND ce3.post_id IS NULL
        )

Então isso parece ser pelo menos uma operação O(n^2), certo? Existem 69.724.384 linhas nessa tabela, então isso não parece uma ideia muito boa.

@Sikamikanico. Se você quiser o plugin de calendário de volta, acho que o que fazer é simplesmente excluir todos os eventos do calendário e você pode começar de novo. A outra coisa que poderíamos fazer seria executar essa consulta no servidor ativo e ver se ela termina.

A causa raiz, eu acho, é um bug no plugin que duplicou eventos quando um fuso horário mudou.

A tabela calendar_events tem 11 GB:

SELECT pg_size_pretty( pg_total_relation_size('calendar_events') );
 pg_size_pretty
----------------
 11 GB
(1 row)

Aqui estão as maiores tabelas:

       relation       | total_size
----------------------+------------
 calendar_events      | 11 GB
 post_timings         | 6884 MB
 posts                | 2292 MB
 user_auth_token_logs | 1240 MB
 user_actions         | 1055 MB
(5 rows)

Apenas calendar_events é claramente bizarro.