Como usar o Modo de Lote com um UNPIVOT (uma junção de loop)?

Eu tenho uma consulta do seguinte formulário:

SELECT ...
FROM ColumnstoreTable cs
CROSS APPLY (
    SELECT *
    FROM (VALUES
        ('A', cs.DataA)
        , ('B', cs.DataB)
        , ('C', cs.DataC)
    ) x(Col0, Col1)
) someValues

Isso pega todas as linhas de uma subconsulta suportada pelo Columnstore ( ColumnstoreTable) e multiplica essas linhas. Isto é essencialmente um UNPIVOT. A consulta real é maior que isso. Esta parte da consulta é alimentada em outro processamento.

O problema aqui é que isso CROSS APPLYé implementado como uma junção de loop, que é uma escolha razoável. Infelizmente, as junções de loop não suportam o modo em lote.

Essa parte da consulta é muito crítica para o desempenho e suspeito que executá-la no modo em lote pode ser muito benéfica para o desempenho.

Como posso reescrever esta consulta para não sair do modo em lote?

Tentei usar uma tabela temporária em vez de VALUES, mas isso não mudou o fato de que não há condição de associação de igualdade na qual a associação de hash.

Uma abordagem pode ser usar uma tabela #temp para os valores e também introduzir uma coluna dummy equijoin para permitir uma junção de hash. Por exemplo:

-- Create a #temp table with a dummy column to match the hash join
-- and the actual column you want
CREATE TABLE #values (dummy INT NOT NULL, Col0 CHAR(1) NOT NULL)
INSERT INTO #values (dummy, Col0)
VALUES (0, 'A'),
        (0, 'B'),
        (0, 'C')
GO

-- A similar query, but with a dummy equijoin condition to allow for a hash join
SELECT v.Col0, 
    CASE v.Col0 
        WHEN 'A' THEN cs.DataA 
        WHEN 'B' THEN cs.DataB 
        WHEN 'C' THEN cs.DataC
        END AS Col1
FROM ColumnstoreTable cs
JOIN #values v
    -- Join your dummy column to any numeric column on the columnstore,
    -- multiplying that column by 0 to ensure a match to all #values
    ON v.dummy = cs.DataA * 0

Plano de desempenho e consulta

Essa abordagem gera um plano de consulta como o seguinte e a correspondência de hash é realizada no modo em lote:

Se eu substituir a SELECTinstrução por uma SUMda CASEinstrução para evitar a necessidade de transmitir todas essas linhas para o console e, em seguida, executar a consulta em uma tabela real de columnstore de linha de 100MM, eu tenho um desempenho bastante bom para gerar os 300MM necessários linhas:

CPU time = 33803 ms, elapsed time = 4363 ms.

E o plano real mostra boa paralelização da junção de hash.

Observações sobre paralelização de junção de hash quando todas as linhas têm o mesmo valor

O desempenho desta consulta depende muito de cada thread no lado da sonda da associação que tem acesso à tabela de hash completa (em oposição a uma versão particionada de hash, que mapeia todas as linhas para um único thread, pois existe apenas um valor distinto para a dummycoluna).

Felizmente, isso é verdade neste caso (como podemos ver pela falta de um Parallelismoperador no lado do probe) e deve ser confiável porque o modo em lote cria uma única tabela de hash compartilhada entre os threads. Portanto, cada thread pode pegar suas linhas Columnstore Index Scane combiná-las com a tabela de hash compartilhada. No SQL Server 2012, essa funcionalidade era muito menos previsível porque um derramamento fazia com que o operador reiniciasse no modo Linha, perdendo o benefício do modo em lote e também exigindo um Repartition Streamsoperador no lado do probe da junção, o que causaria distorção de thread nesse caso . Permitir que os derramamentos permaneçam no modo em lote é uma grande melhoria no SQL Server 2014.

Que eu saiba, o modo de linha não possui esse recurso de tabela de hash compartilhada. No entanto, em alguns casos, geralmente com uma estimativa de menos de 100 linhas no lado da compilação, o SQL Server criará uma cópia separada da tabela de hash para cada thread (identificável pelo Distribute Streamslíder na junção de hash). Isso pode ser muito poderoso, mas é muito menos confiável que o modo em lote, pois depende de suas estimativas de cardinalidade e o SQL Server está tentando avaliar os benefícios versus o custo de criar uma cópia completa da tabela de hash para cada thread.

UNIÃO TUDO: uma alternativa mais simples

Paul White apontou que outra opção, e potencialmente mais simples, seria usar UNION ALLpara combinar as linhas de cada valor. Essa é provavelmente a sua melhor aposta, assumindo que é fácil criar esse SQL dinamicamente. Por exemplo:

SELECT 'A' AS Col0, c.DataA AS Col1
FROM ColumnstoreTable c
UNION ALL
SELECT 'B' AS Col0, c.DataB AS Col1
FROM ColumnstoreTable c
UNION ALL
SELECT 'C' AS Col0, c.DataC AS Col1
FROM ColumnstoreTable c

Isso também gera um plano capaz de utilizar o modo em lote e oferece desempenho ainda melhor do que a resposta original. (Embora em ambos os casos o desempenho seja rápido o suficiente para que qualquer seleção ou gravação de dados em uma tabela se torne rapidamente um gargalo). A UNION ALLabordagem também evita jogar jogos como a multiplicação por 0. Às vezes, é melhor pensar em algo simples!

CPU time = 8673 ms, elapsed time = 4270 ms.