Verificar o 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 mostram que apenas as partições relevantes são lidas (o ideal é um número em vez de KEY). Aplicar uma função/conversão implícita à chave de partição impede o 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.

Com enable_partition_pruning ativado, apenas as partições correspondentes aparecem no plano; as demais aparecem como 'never executed'. Valores constantes são podados no momento do plano; parâmetros, no momento da execução.

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)

No MySQL 5.7+, a coluna 'partitions' da saída do EXPLAIN simples lista as partições a serem varridas (a sintaxe EXPLAIN PARTITIONS foi removida no 8.0); apenas a(s) partição(ões) relevante(s) deve(m) aparecer. Se todas as partições forem listadas, o pruning não está ocorrendo.

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.

A função $PARTITION retorna o número da partição de um valor. Se o número de partições acessadas no plano de execução real estiver próximo de 1, o pruning está em vigor; se todas as partições forem varridas, o predicado não corresponde.

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'.

Se a consulta contiver a shard key, o mongos a direciona apenas ao shard relevante (targeted); caso contrário, ela é enviada a todos os shards (scatter-gather). Verifique os shards acessados na saída do explain.

Redis

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

Os dados são distribuídos pelos hash slots do Cluster; em vez de pruning de consultas, o acesso por chave é direto.

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

O custom routing restringe a consulta a um único shard (semelhante ao pruning). Para dados de séries temporais, um nome de índice com padrão de data (sale-2026-01) garante que apenas os índices relevantes sejam pesquisados; use um padrão restrito em vez de um curinga.