Verificar el 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 muestran que solo se leen las particiones relevantes (lo ideal es un número en lugar de KEY). Aplicar una función/conversión implícita a la clave de partición impide el 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.

Con enable_partition_pruning activado, solo aparecen en el plan las particiones que coinciden; las demás se muestran como 'never executed'. Los valores constantes se podan en tiempo de planificación, los parámetros en tiempo de ejecución.

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)

En MySQL 5.7+, la columna 'partitions' de la salida de EXPLAIN simple lista las particiones que se recorrerán (la sintaxis EXPLAIN PARTITIONS se eliminó en 8.0); solo deben aparecer las particiones relevantes. Si se listan todas, no se está produciendo pruning.

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 función $PARTITION devuelve el número de partición de un valor. Si el número de particiones accedidas en el plan de ejecución real es cercano a 1, el pruning está activo; si se recorren todas las particiones, el predicado no coincide.

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 consulta contiene la shard key, mongos la dirige solo al shard correspondiente (targeted); de lo contrario, se distribuye a todos los shards (scatter-gather). Verifique los shards accedidos en la salida de explain.

Redis

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

Los datos se distribuyen mediante los hash slots de Cluster; en lugar de query pruning, el acceso por clave es directo.

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

El custom routing limita la consulta a un solo shard (similar al pruning). Para datos de series temporales, un nombre de índice con patrón de fecha (sale-2026-01) garantiza que solo se busque en los índices relevantes; use un patrón estrecho en lugar de un comodín.