OK, tengo una selección paralela pero no en la variable de la tabla
Lo anonimicé y:
- BigParallelTable tiene 900k filas y ancho
- Por razones heredadas, BigParallelTable está parcialmente desnormalizado (lo arreglaré más tarde, lo prometo)
- BigParallelTable a menudo genera planes paralelos porque no es ideal y es "caro"
- SQL Server 2005 x64, SP3, compilación 4035, 16 núcleos
Consulta + plan:
DECLARE @FilterList TABLE (bar varchar(100) NOT NULL)
INSERT @FilterList (bar)
SELECT 'val1' UNION ALL 'val2' UNION ALL 'val3'
--snipped
SELECT
*
FROM
dbo.BigParallelTable BPT
JOIN
@FilterList FL ON BPT.Thing = FL.Bar
StmtText
|--Parallelism(Gather Streams)
|--Hash Match(Inner Join, HASH:([FL].[bar])=([BPT].[Thing]), RESIDUAL:(@FilterList.[bar] as [FL].[bar]=[MyDB].[dbo].[BigParallelTable].[Thing] as [BPT].[Thing]))
|--Parallelism(Distribute Streams, Broadcast Partitioning)
| |--Table Scan(OBJECT:(@FilterList AS [FL]))
|--Clustered Index Scan(OBJECT:([MyDB].[dbo].[BigParallelTable].[PK_BigParallelTable] AS [BPT]))
Ahora, pensándolo bien, una variable de tabla es casi siempre un escaneo de tabla, no tiene estadísticas y se supone que es una fila "Número estimado de filas =1", "Real... =3".
¿Podemos declarar que las variables de la tabla no se usan en paralelo, pero el plan contenedor puede usar el paralelismo en otros lugares? Entonces BOL es correcto y el artículo de SQL Storage es incorrecto
