Partitionner ne suffit pas: comprendre le partition pruning

Vous avez déjà lancé une requête SQL sur un gros dataset pourtant partitionné… et attendu… longtemps ?
C’est là qu’intervient une technique aussi simple qu’efficace : le partition pruning 🔥

🎯 Mais c’est quoi exactement ?
Quand vous partitionnez une table (par date, par pays, etc.), le moteur de base peut — s’il est bien guidé — ignorer les partitions qui ne vous concernent pas.
C’est ça le partition pruning : éviter de lire l’inutile.

Exemple concret sur une table « ventes » partitionnée par année :

CREATE TABLE ventes (
id SERIAL,
montant NUMERIC,
annee INT
) PARTITION BY LIST (annee);

CREATE TABLE ventes_2022 PARTITION OF ventes FOR VALUES IN (2022);
CREATE TABLE ventes_2023 PARTITION OF ventes FOR VALUES IN (2023);
CREATE TABLE ventes_2024 PARTITION OF ventes FOR VALUES IN (2024);

EXPLAIN
SELECT COUNT(*) 
FROM ventes 
WHERE annee = 2023;

Aggregate  (cost=...)
  ->  Seq Scan on ventes_2023  (cost=...)

✅ Ici le pruning est actif : seule la partition « ventes_2023 » est lue
❌ Sinon : toutes les partitions sont scannées 😨

⚠️ Le piège classique ?
Écrire une requête qui empêche le moteur de deviner quelle partition utiliser.

❌ Mauvais exemple :

EXPLAIN
SELECT * 
FROM ventes 
WHERE annee = EXTRACT(YEAR FROM CURRENT_DATE);

Aggregate  (cost=...)
  ->  Append  (cost=...)
        ->  Seq Scan on ventes_2022  (cost=...)
        ->  Seq Scan on ventes_2023  (cost=...)
        ->  Seq Scan on ventes_2024  (cost=...)

Ici, bien que la clause where interroge une colonne partitionnée, l’utilisation d’une fonction sur la colonne partitionnée empêche le pruning. Résultat : full scan 👎

🔍 Où ça se joue ?
Tu veux un pruning efficace ?
✔️ C’est à la conception du schéma qu’on y pense (choix des bonnes colonnes de partition)
✔️ Et à l’écriture des requêtes qu’on l’active (structure des filtres)
✔️ Certains outils comme Dataiku ou Tableau peuvent aussi influencer le pruning via la génération automatique de SQL

📌 Pourquoi c’est crucial ?
• Réduit le temps de requête drastiquement
• Diminue le coût sur les moteurs cloud (BigQuery, Snowflake, etc.)
• Améliore la lisibilité des plans d’exécution
• Évite les frustrations (utilisateur & développeur 😅)

🔧 En pratique dans vos projets
Sur une de mes missions en environnement PostgreSQL, activer ce genre d’optimisations m’a permis de :

✅ Réduire des temps d’exécution de 90% (rafraichissement quotidien d’une trentaine de dimensions créée à partir d’une table partitionnée de plus de 200 millions de lignes)
✅ Permettre à une chaîne ELT quotidienne d’avoir le temps de terminer la nuit avant l’arrivée des premiers utilisateurs métiers
✅ Soulager les infrastructures partagées

Et vous ? Connaissiez vous cette mécanique de partition pruning ? 🔍

#DataEngineer #Analytics #DataWarehouse #SQLTips #BusinessIntelligence #DataPlatform

Laisser un commentaire Annuler la réponse