Spark
Nível médioPor que o Spark não está fazendo partition pruning mesmo eu filtrando pela coluna de partição?
Filtrar pela coluna de partição deveria significar que o Spark pula os diretórios que não podem corresponder. Só funciona se o filtro for uma comparação direta, do mesmo tipo, que o planejador consiga resolver antes de ler qualquer coisa.
Uma query que filtra exatamente pela coluna de partição ainda pode escanear toda partição da tabela - e nada no erro (não há nenhum) diz por quê.
O que o partition pruning realmente exige para ativar
O filtro precisa ser uma comparação direta e literal na própria coluna de partição, num tipo que combine com como a partição realmente é armazenada. O planejador precisa conseguir resolver quais diretórios de partição podem ser pulados antes de ler um único arquivo - qualquer coisa que exija ler dados primeiro para avaliar não é pruning, é filtrar depois do fato.
A pegadinha da incompatibilidade de tipo
Uma coluna de partição armazenada como string ("2026-11-02") comparada com um literal do tipo date - ou vice-versa - força um cast implícito. Assim que a expressão do filtro fica envolvida nesse cast, o planejador geralmente não consegue mais empurrá-la para partition pruning; ele lê os arquivos de cada partição e filtra depois, em silêncio, sem nenhum aviso de que o pruning parou de se aplicar.
Filtros derivados também não podam
Filtrar por uma coluna derivada da coluna de partição - date_trunc('month', event_date) numa tabela particionada por event_date - não é reconhecido pelo planejador como o mesmo predicado. Só uma comparação direta com a coluna de partição crua, no seu tipo nativo, realmente poda.
Veja como isso fica no seu próprio pipeline.
Envie um event log real do Spark, um run_results.json do dbt ou uma exportação de métricas do Flink e receba recomendações concretas, para aprovar antes de aplicar - não mais uma regra geral.