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
)
Cela ressemble donc au moins à une opération O(n^2), n’est-ce pas ? Il y a 69 724 384 lignes dans cette table, donc ce n’est pas une très bonne idée.
@Sikamikanico. Si vous voulez récupérer le plugin de calendrier, je pense que la meilleure chose à faire est de supprimer tous les événements du calendrier et de recommencer. L’autre chose que nous pourrions faire serait d’exécuter cette requête sur le serveur actif et de voir si elle se termine un jour.
La cause profonde, je pense, est un bug dans le plugin qui a dupliqué les événements lorsqu’un fuseau horaire a changé.
La table calendar_events fait 11 Go :
SELECT pg_size_pretty( pg_total_relation_size('calendar_events') );
pg_size_pretty
----------------
11 GB
(1 row)
Voici les plus grosses tables :
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)
Seule calendar_events est clairement bizarre.