Merci à tous ici ! J’ai corrigé la clé en double, supprimé les index obsolètes, puis exécuté avec succès :
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
L’utilisation du processeur est revenue à la normale. Ouf.
Question : Pourquoi une base de données non optimisée ou un index corrompu entraîne-t-elle une telle utilisation élevée du CPU par postmaster ? Juste par curiosité.
Je pense que l’index cassé est une fausse piste ; ce n’est certes pas idéal et il doit être corrigé.
Le véritable problème est que ce passage de la version 10 à 12 laisse la base de données avec des statistiques très médiocres, ce qui entraîne une mauvaise performance.
Les performances sont mauvaises car l’optimiseur de requêtes choisit des plans d’exécution très inefficaces, car les statistiques dont il dispose sur les données des tables sont totalement erronées.
Nous intégrerons la reconstruction des statistiques via VACUUM dans notre procédure automatisée de migration.
Merci, @sam, pour les explications. Cela a du sens. Je suppose que c’est une bonne idée d’intégrer la reconstruction dans le déplacement automatisé. Merci encore pour votre aide !