Kan forespørgsler, der læser tabelvariabler, generere parallelle udsendelsesplaner i SQL Server 2008?

OK, jeg har et parallelvalg, men ikke på tabelvariablen

Jeg har anonymiseret det og:

• BigParallelTable er 900.000 rækker og bred
• Af ældre årsager er BigParallelTable delvist denormaliseret (jeg ordner det senere, lover)
• BigParallelTable genererer ofte parallelle planer, fordi det ikke er ideelt og er "dyrt"
• SQL Server 2005 x64, SP3, build 4035, 16 kerner

Forespørgsel + 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]))

Når man nu tænker over det, er en tabelvariabel næsten altid en tabelscanning, har ingen statistik og antages én række "Estimeret antal rækker =1", "Faktisk.. =3".

Kan vi erklære, at tabelvariabler ikke bruges parallelt, men den indeholdende plan kan bruge parallelisme andre steder? Så BOL er korrekt, og SQL Storage-artiklen er forkert