Vacuum et maintenance

Prérequis : cours précédents.

Pourquoi

Postgres ne supprime pas vraiment tout de suite (MVCC : les vieilles versions restent jusqu'au ménage). Sans maintenance, les tables gonflent, les index se traînent, et un jour les transactions se figent (XID wraparound — l'arrêt cardiaque).

Concepts

• MVCC : chaque UPDATE crée une nouvelle version, l'ancienne devient « morte ». Les lecteurs voient une image cohérente sans verrous — au prix du ménage.
• VACUUM : récupère l'espace des lignes mortes (ordinaire) ; VACUUM FULL : réécrit la table (verrou exclusif ! à éviter en prod) ; ANALYZE : met à jour les stats de l'optimiseur.
• Autovacuum : le ménage auto — à laisser actif et à surveiller (pg_stat_user_tables : n_dead_tup qui explose = autovacuum dépassé). Réglages selon le rythme d'écriture, pas par défaut aveugle.
• Bloat : table/index gonflés de vide. Symptôme : table de 100k lignes qui pèse des Go et des seq scans lents malgré les index.

Exemple : surveiller

SELECT relname, n_dead_tup, last_autovacuum, last_autoanalyze
FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 10;
-- n_dead_tup énorme + last_autovacuum vieux = autovacuum à l'agonie : régler ou vacuum manuel hors pointe

Cas réel

Table de logs sans vacuum adapté (100M d'updates/mois) : 40 Go dont 30 de vide, requêtes ×10 plus lentes. VACUUM (VERBOSE, ANALYZE) hors pointe + réglage autovacuum par table : retour à 12 Go et aux perfs nominales.

Pièges

• Désactiver autovacuum « pour les perfs » : l'arrêt cardiaque XID (base en lecture seule forcée) en quelques mois sur base active.
• VACUUM FULL en journée : verrou exclusif = table inaccessible. Jamais en prod active (ou pg_repack).
• Oublier ANALYZE après gros chargement : stats fausses → plans absurdes → EXPLAIN qui ment.

À retenir

MVCC = ménage obligatoire ; autovacuum actif ET surveillé ; ANALYZE après chargements ; FULL jamais en journée.