OK, eu tenho uma seleção paralela, mas não na variável da tabela
Eu anonimizei e:
- BigParallelTable tem 900 mil linhas e largura
- Por motivos de legado, BigParallelTable foi parcialmente desnormalizado (vou corrigi-lo mais tarde, prometo)
- BigParallelTable geralmente gera planos paralelos porque não é ideal e é "caro"
- SQL Server 2005 x64, SP3, compilação 4035, 16 núcleos
Consulta + plano:
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]))
Agora, pensando bem, uma variável de tabela é quase sempre uma varredura de tabela, não possui estatísticas e assume uma linha "Número estimado de linhas =1", "Real.. =3".
Podemos declarar que as variáveis da tabela não são usadas em paralelo, mas o plano de contenção pode usar paralelismo em outro lugar? Então BOL está correto e o artigo SQL Storage está errado
