Skip to content

10.2-analyze.md

Latest commit

 

History

History
847 lines (612 loc) · 24 KB

10.2-analyze.md

File metadata and controls

847 lines (612 loc) · 24 KB

🔝 Retour au Sommaire

16.10.2. ANALYZE : Mise à jour des statistiques du planificateur

Introduction : Le problème de la navigation à l'aveugle

Imaginez que vous devez organiser un voyage en voiture :

  • Sans carte ni GPS : Vous roulez au hasard, vous vous perdez, vous perdez du temps
  • Avec une carte à jour : Vous connaissez les routes, les distances, les limitations, vous choisissez le meilleur itinéraire

PostgreSQL fonctionne de la même manière pour exécuter vos requêtes SQL !

Pour chaque requête, PostgreSQL doit décider :

  • Quel index utiliser (ou ne pas utiliser) ?
  • Dans quel ordre joindre les tables ?
  • Quelle stratégie de scan adopter ?

Pour prendre ces décisions intelligemment, PostgreSQL a besoin de statistiques à jour sur vos données. C'est exactement le rôle d'ANALYZE.

Qu'est-ce qu'ANALYZE ?

ANALYZE est une commande qui :

  1. Collecte des statistiques sur le contenu de vos tables
  2. Stocke ces statistiques dans les tables système (pg_statistics)
  3. Permet au planificateur de choisir le meilleur plan d'exécution pour vos requêtes

Syntaxe de base

ANALYZE;                    -- Analyse toute la base de données  
ANALYZE nom_table;          -- Analyse une table spécifique  
ANALYZE nom_table (col1, col2);  -- Analyse des colonnes spécifiques

Différence clé avec VACUUM

VACUUM ANALYZE
Nettoie les lignes mortes Collecte des statistiques
Récupère l'espace disque N'affecte pas l'espace disque
Prévient le XID wraparound Optimise les plans de requêtes
Impact : Santé de la base Impact : Performance des requêtes

Bonne pratique : Souvent utilisés ensemble avec VACUUM ANALYZE.

Le planificateur de requêtes : Le cerveau de PostgreSQL

Qu'est-ce que le planificateur ?

Le Query Planner (ou planificateur de requêtes) est le composant de PostgreSQL qui :

  1. Reçoit votre requête SQL
  2. Génère plusieurs plans d'exécution possibles
  3. Estime le coût de chaque plan
  4. Choisit le plan le moins coûteux

Exemple simple

Prenons cette requête :

SELECT * FROM clients WHERE ville = 'Paris';

Le planificateur a plusieurs options :

Option A - Sequential Scan :

  • Parcourir toute la table ligne par ligne
  • Coût estimé : 10 000 unités

Option B - Index Scan :

  • Utiliser un index sur la colonne ville
  • Coût estimé : 150 unités

Décision : Le planificateur choisit l'index (Option B) car c'est plus rapide !

Comment le planificateur estime-t-il les coûts ?

Le planificateur utilise des statistiques pour évaluer :

  1. Nombre de lignes dans la table (n_live_tup)
  2. Nombre de lignes qui correspondent au filtre (sélectivité)
  3. Distribution des valeurs (valeurs les plus fréquentes, histogrammes)
  4. Taille des données (pages, tuples)
  5. Corrélation entre l'ordre physique et l'ordre logique

Sans statistiques à jour, le planificateur est aveugle !

Quelles statistiques ANALYZE collecte-t-il ?

1. Statistiques de base

Pour chaque table :

-- Voir les statistiques d'une table
SELECT
    schemaname,
    tablename,
    n_live_tup,        -- Nombre de lignes vivantes
    n_dead_tup,        -- Nombre de lignes mortes
    last_analyze,      -- Dernière analyse manuelle
    last_autoanalyze   -- Dernière analyse automatique
FROM pg_stat_user_tables  
WHERE tablename = 'clients';

2. Statistiques par colonne

Pour chaque colonne, PostgreSQL collecte :

  • null_frac : Proportion de valeurs NULL
  • avg_width : Largeur moyenne des valeurs (en octets)
  • n_distinct : Nombre de valeurs distinctes (cardinalité)
  • most_common_vals : Les valeurs les plus fréquentes (MCV)
  • most_common_freqs : Fréquences de ces valeurs
  • histogram_bounds : Distribution des valeurs (pour les autres valeurs)
  • correlation : Corrélation entre ordre physique et logique

Exemple : Voir les statistiques d'une colonne

-- Voir les statistiques de la colonne "ville"
SELECT
    attname,
    n_distinct,
    most_common_vals,
    most_common_freqs
FROM pg_stats  
WHERE tablename = 'clients'  
  AND attname = 'ville';

Résultat possible :

attname | n_distinct | most_common_vals              | most_common_freqs
--------|------------|-------------------------------|------------------
ville   | 50         | {Paris,Lyon,Marseille,Lille}  | {0.35,0.15,0.12,0.08}

Interprétation :

  • Il y a 50 villes distinctes
  • 35% des clients sont à Paris
  • 15% à Lyon, 12% à Marseille, 8% à Lille

Le planificateur utilise ces informations pour estimer combien de lignes retournera WHERE ville = 'Paris' → environ 35% !

Comment ANALYZE collecte-t-il les statistiques ?

Échantillonnage (Sampling)

ANALYZE ne lit pas toute la table ! Il utilise un échantillonnage statistique :

  1. Sélection aléatoire de pages (blocs de 8 Ko)
  2. Lecture d'un échantillon de lignes
  3. Extrapolation des statistiques à toute la table

Paramètre clé : default_statistics_target

-- Voir le paramètre actuel
SHOW default_statistics_target;  -- Défaut : 100

Ce paramètre contrôle :

  • Nombre d'échantillons collectés par ANALYZE
  • Précision des statistiques (histogrammes, MCV)
  • Temps d'exécution d'ANALYZE

Valeurs :

  • 10 : Rapide mais imprécis
  • 100 : Défaut, bon équilibre
  • 1000 : Très précis mais lent (pour les colonnes critiques)
  • 10000 : Maximum, pour les cas extrêmes

Ajuster pour une colonne spécifique

Si une colonne est cruciale pour vos requêtes (ex : dans les WHERE, JOIN) :

-- Augmenter la précision des statistiques pour la colonne "ville"
ALTER TABLE clients  
ALTER COLUMN ville SET STATISTICS 500;  

-- Puis relancer ANALYZE
ANALYZE clients (ville);

Impact :

  • ✅ Meilleure estimation du planificateur pour cette colonne
  • ⚠️ ANALYZE sera un peu plus lent sur cette colonne

Les symptômes de statistiques obsolètes

1. Plans de requêtes sous-optimaux

Exemple classique : Le planificateur choisit un Sequential Scan alors qu'un Index Scan serait plus rapide.

EXPLAIN SELECT * FROM commandes WHERE client_id = 12345;

Avec statistiques obsolètes :

Seq Scan on commandes  (cost=0.00..25000.00 rows=500000 width=100)
  Filter: (client_id = 12345)

→ Le planificateur pense qu'il y a 500 000 lignes, alors qu'en réalité il n'y en a que 50.

Avec statistiques à jour :

Index Scan using idx_commandes_client_id on commandes
  (cost=0.42..8.44 rows=50 width=100)
  Index Cond: (client_id = 12345)

→ Le planificateur sait qu'il y a 50 lignes, il choisit l'index !

2. Performances qui se dégradent progressivement

Vous remarquez que vos requêtes deviennent de plus en plus lentes avec le temps, sans raison apparente :

  • Les données ont beaucoup évolué (insertions, suppressions)
  • Les statistiques ne reflètent plus la réalité
  • Le planificateur fait de mauvais choix

Solution : ANALYZE !

3. Estimations complètement fausses

Dans l'output d'EXPLAIN ANALYZE, vous voyez :

→ Index Scan (cost=... rows=10 ...) (actual rows=100000 ...)
  • rows=10 : Estimation du planificateur
  • actual rows=100000 : Réalité

Ratio estimation/réalité de 1:10 000 → Statistiques obsolètes !

Quand lancer ANALYZE manuellement ?

Situations typiques

  1. Après un chargement massif de données

    -- Import de 10 millions de lignes
COPY clients FROM '/data/clients.csv' WITH CSV;

-- ANALYZE immédiatement après
ANALYZE clients;

  2. Après des modifications massives

    -- Mise à jour de 50% de la table
UPDATE produits SET prix = prix * 1.1 WHERE categorie = 'electronique';

-- ANALYZE pour mettre à jour les distributions
ANALYZE produits;

  3. Après une suppression importante

    -- Suppression de 80% des anciennes données
DELETE FROM logs WHERE created_at < NOW() - INTERVAL '90 days';

-- ANALYZE (souvent avec VACUUM)
VACUUM ANALYZE logs;

  4. Avant une requête critique

    -- Vous allez lancer une requête complexe importante
ANALYZE;  -- Assure que les statistiques sont fraîches

-- Puis votre requête complexe
SELECT ... FROM ... WHERE ... JOIN ... ;

  5. Après la création d'un index

    CREATE INDEX idx_clients_email ON clients(email);

-- ANALYZE pour que le planificateur connaisse l'index
ANALYZE clients;

Auto-ANALYZE : Le pilote automatique

Comme pour VACUUM, PostgreSQL dispose d'auto-ANALYZE qui lance automatiquement ANALYZE quand c'est nécessaire.

Comment auto-ANALYZE se déclenche-t-il ?

Formule de déclenchement :

Seuil = autovacuum_analyze_threshold + (autovacuum_analyze_scale_factor × nombre_total_de_lignes)

Paramètres par défaut :

SHOW autovacuum_analyze_threshold;     -- 50 lignes modifiées  
SHOW autovacuum_analyze_scale_factor;  -- 0.1 (10% de la table)

Exemple :

  • Table avec 100 000 lignes
  • Seuil = 50 + (0.1 × 100 000) = 10 050 modifications
  • Auto-ANALYZE se déclenche après 10 050 INSERT/UPDATE/DELETE

Vérifier l'activité d'auto-ANALYZE

-- Voir les dernières auto-analyses
SELECT
    schemaname,
    tablename,
    last_analyze,
    last_autoanalyze,
    analyze_count,
    autoanalyze_count,
    n_mod_since_analyze  -- Nombre de modifications depuis le dernier ANALYZE
FROM pg_stat_user_tables  
WHERE schemaname = 'public'  
ORDER BY n_mod_since_analyze DESC;

Indicateurs :

  • n_mod_since_analyze > 10 000 → ANALYZE devrait se déclencher bientôt
  • last_autoanalyze très ancien avec beaucoup de modifications → Problème potentiel

Nouveautés PostgreSQL 18 : ANALYZE amélioré

1. Statistiques VACUUM et ANALYZE dans pg_stat_all_tables

PostgreSQL 18 enrichit la vue pg_stat_all_tables avec de nouvelles métriques :

-- Nouvelles colonnes dans PG 18
SELECT
    schemaname,
    tablename,
    last_vacuum,
    last_autovacuum,
    last_analyze,
    last_autoanalyze,
    vacuum_count,
    autovacuum_count,
    analyze_count,
    autoanalyze_count,
    n_ins_since_vacuum,      -- Nouveau PG 18
    n_del_since_vacuum,      -- Nouveau PG 18
    n_mod_since_analyze      -- Amélioré PG 18
FROM pg_stat_all_tables  
WHERE schemaname = 'public';

Avantages :

  • Meilleure visibilité sur l'activité de maintenance
  • Détection plus facile des tables nécessitant ANALYZE
  • Monitoring plus fin

2. Auto-ANALYZE plus réactif

Avec les améliorations de PG 18 sur autovacuum, auto-ANALYZE bénéficie aussi de :

  • Meilleure allocation des workers
  • Ajustements dynamiques selon la charge
  • Réactivité accrue sur les tables à forte activité

ANALYZE vs VACUUM ANALYZE

Quand utiliser quoi ?

Commande Quand l'utiliser
ANALYZE Vous voulez uniquement mettre à jour les statistiques (rapide)
VACUUM ANALYZE Vous voulez nettoyer ET mettre à jour les statistiques (plus lent)
VACUUM Vous voulez uniquement nettoyer (sans mise à jour des stats)

Temps d'exécution

ANALYZE est très rapide comparé à VACUUM :

  • ANALYZE : Échantillonnage, ne lit pas toute la table → quelques secondes même sur de grosses tables
  • VACUUM : Parcourt toute la table pour nettoyer → plusieurs minutes à heures

Exemple :

-- Sur une table de 100 millions de lignes
ANALYZE clients;          -- ~5 secondes  
VACUUM clients;           -- ~10 minutes  
VACUUM ANALYZE clients;   -- ~10 minutes (VACUUM + quelques secondes pour ANALYZE)

Monitoring des statistiques

1. Vérifier si les statistiques sont à jour

-- Tables avec beaucoup de modifications depuis le dernier ANALYZE
SELECT
    schemaname || '.' || tablename AS table_name,
    pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) AS size,
    n_live_tup,
    n_mod_since_analyze,
    ROUND(n_mod_since_analyze * 100.0 / NULLIF(n_live_tup, 0), 2) AS pct_modified,
    last_analyze,
    last_autoanalyze
FROM pg_stat_user_tables  
WHERE n_mod_since_analyze > 1000  
ORDER BY n_mod_since_analyze DESC  
LIMIT 20;

Indicateurs :

  • pct_modified > 10% → ANALYZE recommandé
  • pct_modified > 20% → ANALYZE urgent

2. Identifier les colonnes avec peu de statistiques

-- Colonnes avec statistiques par défaut (peut-être insuffisantes)
SELECT
    schemaname || '.' || tablename AS table_name,
    attname AS column_name,
    n_distinct,
    null_frac
FROM pg_stats  
WHERE schemaname = 'public'  
  AND n_distinct BETWEEN -1 AND 100  -- Peu de valeurs distinctes détectées
ORDER BY tablename, attname;

3. Détecter les plans de requêtes avec mauvaises estimations

Utilisez EXPLAIN ANALYZE et comparez rows (estimation) vs actual rows :

EXPLAIN ANALYZE  
SELECT * FROM commandes WHERE statut = 'livree';

Output :

Seq Scan on commandes  (cost=0.00..1500.00 rows=5000 width=200)
                       (actual time=0.050..25.123 rows=95000 loops=1)
  • rows=5000 (estimation) vs actual rows=95000 (réalité)
  • Ratio de 1:19 → Les statistiques sont obsolètes !

Solution :

ANALYZE commandes;

Cas pratiques et exemples

Cas 1 : Import quotidien de données

Contexte : Vous importez 1 million de lignes chaque nuit dans une table transactions.

-- Script d'import
BEGIN;

-- Import des données
COPY transactions FROM '/data/daily_transactions.csv' WITH CSV;

-- ANALYZE immédiatement après pour que les requêtes du matin soient optimales
ANALYZE transactions;

COMMIT;

Pourquoi ? Les requêtes du matin utiliseront des statistiques fraîches et seront rapides.

Cas 2 : Requête lente inexpliquée

Problème : Une requête qui était rapide est devenue lente.

-- Requête lente
SELECT COUNT(*) FROM ventes WHERE pays = 'France';

Diagnostic :

-- 1. Vérifier les statistiques
SELECT
    last_analyze,
    n_mod_since_analyze,
    n_live_tup
FROM pg_stat_user_tables  
WHERE tablename = 'ventes';  

-- Résultat : last_analyze = il y a 30 jours, n_mod_since_analyze = 500000 !

-- 2. Lancer ANALYZE
ANALYZE ventes;

-- 3. Relancer la requête → Rapide à nouveau !

Cas 3 : Nouvelle colonne avec index

Contexte : Vous ajoutez une colonne et créez un index dessus.

-- Ajout d'une colonne
ALTER TABLE clients ADD COLUMN score_fidelite INT;

-- Remplissage
UPDATE clients SET score_fidelite = FLOOR(RANDOM() * 100);

-- Création d'un index
CREATE INDEX idx_clients_score ON clients(score_fidelite);

-- ANALYZE pour que le planificateur connaisse la distribution
ANALYZE clients (score_fidelite);

-- Maintenant les requêtes utilisent efficacement l'index
SELECT * FROM clients WHERE score_fidelite > 80;

Cas 4 : Table avec distribution de données très inégale

Contexte : Une table produits où 90% des produits sont de catégorie "standard" et 10% "premium".

-- Augmenter la précision des statistiques pour la colonne critique
ALTER TABLE produits  
ALTER COLUMN categorie SET STATISTICS 1000;  

-- ANALYZE avec statistiques détaillées
ANALYZE produits (categorie);

-- Vérifier les statistiques collectées
SELECT
    attname,
    n_distinct,
    most_common_vals,
    most_common_freqs
FROM pg_stats  
WHERE tablename = 'produits' AND attname = 'categorie';

Résultat : Le planificateur peut maintenant différencier efficacement les requêtes sur "standard" (beaucoup de lignes) vs "premium" (peu de lignes).

Bonnes pratiques

1. Faire confiance à auto-ANALYZE

Dans la plupart des cas, auto-ANALYZE suffit :

  • ✅ Activé par défaut (via autovacuum)
  • ✅ Se déclenche automatiquement selon l'activité
  • ✅ Léger et non bloquant

2. ANALYZE manuel dans ces situations

  • ✅ Après un import/export massif
  • ✅ Après création d'index
  • ✅ Avant une migration ou une opération critique
  • ✅ En cas de requête lente avec mauvaises estimations

3. Combiner avec VACUUM après modifications importantes

-- Après une grosse opération
VACUUM ANALYZE ma_table;

Cela nettoie ET met à jour les statistiques en une seule passe.

4. Ajuster statistics_target pour les colonnes critiques

Pour les colonnes fréquemment utilisées dans WHERE, JOIN, ORDER BY :

ALTER TABLE ma_table  
ALTER COLUMN colonne_importante SET STATISTICS 500;  

ANALYZE ma_table (colonne_importante);

5. Monitorer régulièrement

Mettez en place des alertes sur :

  • Tables avec n_mod_since_analyze élevé
  • Tables avec last_autoanalyze ancien (> 7 jours)
  • Requêtes avec écarts importants entre estimations et réalité

6. Ne pas abuser d'ANALYZE

ANALYZE est léger mais pas gratuit :

  • ❌ Ne pas lancer ANALYZE après chaque INSERT
  • ✅ Lancer ANALYZE après des modifications significatives (> 10% de la table)

7. ANALYZE après CREATE INDEX

Toujours analyser après la création d'un index :

CREATE INDEX idx_nouveau ON ma_table(colonne);  
ANALYZE ma_table;  -- Important !

Cela permet au planificateur de connaître immédiatement le nouvel index.

Dépannage et troubleshooting

Problème 1 : Auto-ANALYZE ne se déclenche jamais

Symptômes : last_autoanalyze est NULL ou très ancien.

Causes possibles :

  1. Autovacuum désactivé

    SHOW autovacuum;  -- Vérifier que c'est 'on'

  2. Seuil trop élevé pour une petite table

    -- Ajuster pour la table spécifique
ALTER TABLE petite_table SET (
    autovacuum_analyze_threshold = 10,
    autovacuum_analyze_scale_factor = 0.05
);

Problème 2 : ANALYZE est très lent

Causes :

  • default_statistics_target trop élevé
  • Table très grande avec beaucoup de colonnes
  • I/O disque saturé

Solutions :

-- Analyser seulement les colonnes importantes
ANALYZE ma_table (col1, col2, col3);

-- Réduire temporairement statistics_target
SET default_statistics_target = 50;  
ANALYZE ma_table;  
RESET default_statistics_target;

Problème 3 : Estimations toujours fausses malgré ANALYZE

Causes :

  • Distribution de données très atypique
  • Corrélation entre colonnes non capturée
  • Statistics_target insuffisant

Solutions :

-- Augmenter drastiquement pour la colonne problématique
ALTER TABLE ma_table  
ALTER COLUMN colonne_problematique SET STATISTICS 5000;  

ANALYZE ma_table (colonne_problematique);

-- Vérifier les nouvelles statistiques
SELECT * FROM pg_stats  
WHERE tablename = 'ma_table'  
  AND attname = 'colonne_problematique';

ANALYZE en production : Checklist

Checklist de maintenance quotidienne

✅ Vérifier auto-ANALYZE :

SELECT COUNT(*) FROM pg_stat_user_tables  
WHERE n_mod_since_analyze > 10000;  
-- Devrait être proche de 0

✅ Identifier les tables "en retard" :

SELECT tablename, n_mod_since_analyze, last_autoanalyze  
FROM pg_stat_user_tables  
WHERE n_mod_since_analyze > 10000  
ORDER BY n_mod_since_analyze DESC;

✅ ANALYZE manuel si nécessaire :

ANALYZE; -- Ou sur tables spécifiques

Checklist avant déploiement

  • ✅ Après migration de données : ANALYZE;
  • ✅ Après changement de schéma : ANALYZE tables_modifiées;
  • ✅ Après création d'index : ANALYZE tables_indexées;

Checklist de monitoring hebdomadaire

  • ✅ Audit des statistiques obsolètes
  • ✅ Vérification des ratios estimation/réalité dans les requêtes lentes
  • ✅ Ajustement des statistics_target si nécessaire

Résumé

ANALYZE en 5 points clés

  1. Collecte de statistiques : ANALYZE échantillonne vos données pour collecter des statistiques
  2. Optimisation du planificateur : Ces statistiques permettent au planificateur de choisir les meilleurs plans d'exécution
  3. Auto-ANALYZE : Processus automatique qui gère la plupart des cas
  4. Rapide et léger : ANALYZE est beaucoup plus rapide que VACUUM
  5. Complémentaire à VACUUM : Souvent utilisé ensemble (VACUUM ANALYZE)

Quand lancer ANALYZE ?

Situation Action
Import massif de données ✅ ANALYZE immédiat
Création d'index ✅ ANALYZE immédiat
Modifications importantes (>10% de la table) ✅ ANALYZE manuel
Requêtes avec mauvaises estimations ✅ ANALYZE puis vérifier
Maintenance quotidienne normale ⚪ Auto-ANALYZE suffit

ANALYZE vs VACUUM

┌─────────────────────────────────────────┐
│  VACUUM          ANALYZE                │
│  ─────────────────────────────────────  │
│  Nettoie         Collecte statistiques  │
│  Récupère        N'affecte pas          │
│  l'espace        l'espace disque        │
│  Lent (minutes)  Rapide (secondes)      │
│  Santé DB        Performance requêtes   │
└─────────────────────────────────────────┘

Concepts avancés (Bonus)

La vue pg_stats : Explorer les statistiques

-- Explorer toutes les statistiques d'une table
SELECT * FROM pg_stats WHERE tablename = 'clients' \gx

Colonnes intéressantes :

  • n_distinct : Nombre de valeurs distinctes (-1 = unique, positif = estimé)
  • most_common_vals : Top N valeurs les plus fréquentes
  • most_common_freqs : Leurs fréquences
  • histogram_bounds : Distribution des valeurs restantes
  • correlation : Corrélation ordre physique/logique (important pour les index)

Extended Statistics (Statistiques étendues)

Pour les colonnes corrélées, PostgreSQL 10+ permet de créer des statistiques étendues :

-- Exemple : colonnes ville et code_postal sont corrélées
CREATE STATISTICS stats_ville_cp (dependencies)  
ON ville, code_postal FROM clients;  

ANALYZE clients;

-- Le planificateur comprend maintenant la corrélation

Statistics Targets extrêmes

Pour des cas très spécifiques :

-- Maximum absolu
ALTER TABLE ma_table ALTER COLUMN col SET STATISTICS 10000;

-- Désactiver les statistiques (rare, pour debugging)
ALTER TABLE ma_table ALTER COLUMN col SET STATISTICS 0;

Conclusion

ANALYZE est l'outil qui permet à PostgreSQL de prendre des décisions intelligentes :

  • 🧠 Cerveau du planificateur : Fournit les données nécessaires aux décisions
  • ⚡ Rapide et léger : Quelques secondes même sur de grosses tables
  • 🤖 Automatisé : Auto-ANALYZE gère la plupart des cas
  • 🎯 Impact direct sur les performances : Meilleures requêtes = application plus rapide

En tant que développeur ou DevOps, retenez :

  • Auto-ANALYZE fait le travail, mais surveillez les tables à forte activité
  • ANALYZE manuel après imports/modifications massives (> 10% de la table)
  • Combinez VACUUM ANALYZE après nettoyage de données
  • Ajustez statistics_target pour les colonnes critiques
  • Surveillez les estimations dans vos requêtes lentes (EXPLAIN ANALYZE)

PostgreSQL 18 améliore encore le système de statistiques avec de nouvelles métriques dans pg_stat_all_tables, vous donnant une visibilité encore meilleure sur la santé de vos bases de données.

Avec VACUUM (maintenance physique) et ANALYZE (optimisation du planificateur), vous disposez des deux piliers essentiels pour maintenir PostgreSQL en pleine forme !

Prochaines étapes recommandées :

  • Approfondir EXPLAIN et le planificateur (Chapitre 13.7)
  • Explorer les index et leur impact sur les plans (Chapitre 13)
  • Découvrir pg_stat_statements pour l'analyse des requêtes (Chapitre 14.1)

⏭️ Nouveauté PG 18 : Autovacuum et ajustements dynamiques (autovacuum_worker_slots)