Vérifier le partition pruning

Oracle

EXPLAIN PLAN FOR
SELECT * FROM sale WHERE sale_date = DATE '2026-01-15';
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
-- Look for 'PARTITION RANGE ITERATOR/SINGLE' and the Pstart/Pstop columns in the plan.

Pstart/Pstop montrent que seules les partitions concernées sont lues (un nombre plutôt que KEY est idéal). Appliquer une fonction/conversion implicite à la clé de partitionnement empêche le pruning.

PostgreSQL

SET enable_partition_pruning = on;
EXPLAIN (ANALYZE)
SELECT * FROM sale WHERE sale_date = DATE '2026-01-15';
-- Verify in the plan that only the relevant partition (child table) is scanned.

Avec enable_partition_pruning activé, seules les partitions correspondantes apparaissent dans le plan ; les autres sont indiquées 'never executed'. Les valeurs constantes sont élaguées à la planification, les paramètres à l'exécution.

MySQL

-- Show which partitions are scanned:
EXPLAIN SELECT * FROM sale WHERE sale_date = '2026-01-15';
-- 5.7 and earlier: EXPLAIN PARTITIONS SELECT ... (removed in 8.0)

Dans MySQL 5.7+, la colonne 'partitions' de la sortie EXPLAIN simple liste les partitions à parcourir (la syntaxe EXPLAIN PARTITIONS a été supprimée en 8.0) ; seule(s) la ou les partitions concernées doivent apparaître. Si toutes les partitions sont listées, le pruning n'a pas lieu.

SQL Server

-- Find which partition a value falls into:
SELECT $PARTITION.pf_sale_date('2026-01-15') AS partition_no;
-- Examine 'Actual Partition Count' and 'Actual Partitions Accessed' in the actual plan.

La fonction $PARTITION renvoie le numéro de partition d'une valeur. Si le nombre de partitions accédées dans le plan d'exécution réel est proche de 1, le pruning est actif ; si toutes les partitions sont parcourues, le prédicat ne correspond pas.

MongoDB

// Targeted query using the shard key in a sharded cluster:
db.sale.find({ shop_id: 42 }).explain("executionStats")
// In explain, only the relevant shard should appear under 'shards'.

Si la requête contient la shard key, mongos ne la route que vers le shard concerné (targeted) ; sinon elle est diffusée à tous les shards (scatter-gather). Vérifiez les shards accédés dans la sortie explain.

Redis

# Not applicable: there is no table/partition concept.

Les données sont réparties via les hash slots du Cluster ; au lieu d'un élagage des requêtes, l'accès par clé est direct.

Elasticsearch

# Route to the relevant shard with routing:
GET <index>/_search?routing=customer42
{ "query": { "term": { "customer_id": 42 } } }
# Query only the relevant indices with a time-based index pattern:
GET sale-2026-01/_search

Le routing personnalisé restreint la requête à un seul shard (similaire au pruning). Pour les données temporelles, un nom d'index daté (sale-2026-01) garantit que seuls les indices concernés sont interrogés ; utilisez un motif étroit plutôt qu'un caractère générique.