Hola Lars,
Gracias por tu respuesta. Actualmente estoy en un sistema de desarrollo y, por lo tanto, no tengo conjuntos de datos grandes para trabajar / probar mis teorías, y no estaba seguro de cómo el optimizador considera las estadísticas de las tablas al generar su plan de ejecución.
Sin embargo, tu respuesta me inspiró y decidí generar algunos datos de prueba. 30 minutos más tarde, tengo una tabla FACT de 5 millones de filas y una tabla DIM de 1,000 filas.
Por cierto, estoy ejecutando la revisión 82 (¡muy antigua, lo sé!).
En cualquier caso, mis hallazgos coinciden con los tuyos en que definitivamente hay un sobrecosto al filtrar en la tabla DIM y unirla a la tabla FACT, ya que el filtro se aplica primero a ambas tablas antes de la unión. ¡Supongo que lo bueno de la tabla de almacenamiento de columnas es que este tipo de filtros son muy rápidos incluso en ausencia de índices secundarios!
select
*
from
fact
where
fact.prod_id not in (9, 99, 999)
| NOMBRE_DEL_OPERADOR | DETALLES_DEL_OPERADOR |
vs
select
*
from
fact inner join dim on
fact.prod_id = dim.prod_id
where
dim.prod_id not in (9, 99, 999)
| NOMBRE_DEL_OPERADOR | DETALLES_DEL_OPERADOR |
Del mismo modo que con tus hallazgos, observo el mismo comportamiento ya sea que se utilice el motor de COLUMN o OLAP, con el rendimiento del motor OLAP aumentando significativamente con la agregación creciente (naturalmente).
Y sí, definitivamente estamos haciendo uso de la unión en estrella en nuestros escenarios de modelado. Esta pregunta estaba más dirigida a unir tablas transaccionales juntas (solo usé la etiqueta de fact / dim por simplicidad).
Gracias de nuevo,
Chris.
