Olá Lars,
Obrigado pela sua resposta. Atualmente estou em um sistema de desenvolvimento e, portanto, não tenho grandes conjuntos de dados para trabalhar/testar minhas teorias, e não estava certo de como o otimizador considera as estatísticas das tabelas ao gerar seu plano de execução.
No entanto, sua resposta me inspirou e decidi gerar alguns dados de teste. 30 minutos depois, tenho uma tabela FACT com 5 milhões de linhas e uma tabela DIM com 1.000 linhas.
Aliás, estou executando a revisão 82 (bem antiga, eu sei!).
De qualquer forma, meus achados coincidem com os seus de que definitivamente há um custo adicional ao filtrar na tabela DIM e uni-la com a tabela FACT, já que o filtro é aplicado primeiro em ambas as tabelas antes da união. Suponho que a vantagem da tabela de armazenamento de colunas é que esse tipo de filtro é muito rápido mesmo na ausência de índices secundários!
select
*
from
fact
where
fact.prod_id not in (9, 99, 999)
| NOME_DO_OPERADOR | DETALHES_DO_OPERADOR |
vs
select
*
from
fact inner join dim on
fact.prod_id = dim.prod_id
where
dim.prod_id not in (9, 99, 999)
| NOME_DO_OPERADOR | DETALHES_DO_OPERADOR |
Da mesma forma que com suas descobertas, observo o mesmo comportamento, seja usando o motor de COLUNA ou OLAP, com o desempenho do motor OLAP aumentando significativamente com a agregação crescente (naturalmente).
E sim, definitivamente estamos usando a união em estrela em nossos cenários de modelagem. Esta questão era mais direcionada a unir tabelas transacionais juntas (apenas usei a etiqueta de fact/dim por simplicidade).
Obrigado novamente,
Chris.
