Grazie a tutti! Ho corretto la chiave duplicata, eliminato gli indici obsoleti e poi eseguito con successo:
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
L’utilizzo della CPU è tornato alla normalità. Fiuu.
Domanda: perché un database non ottimizzato o un indice danneggiato causano un utilizzo della CPU così elevato da parte di postmaster? Sono solo curioso.
Penso che l’indice rotto sia un falso allarme; certamente non è ottimale e dovrebbe essere corretto.
Il problema principale è che questo passaggio da 10 a 12 lascia il database con statistiche inadeguate, il che porta a prestazioni scadenti.
Le prestazioni sono scarse perché l’ottimizzatore delle query sceglie piani di esecuzione molto inefficienti, poiché le statistiche che possiede sui dati nelle tabelle sono completamente errate.
Integreremo la ricostituzione delle statistiche tramite vacuum nel nostro processo automatizzato di migrazione.
Grazie, @sam, per le spiegazioni. Ha senso. Immagino che sia una buona idea integrare la ricostruzione nel processo di spostamento automatizzato. Ancora grazie per il tuo aiuto!