O suporte para Parallel Scalar UDF é uma solicitação de recurso razoável?

Está razoavelmente bem documentado que os UDFs forçam um plano serial geral.

Não tenho certeza se tudo está bem documentado.

• Uma função T-SQL escalar impede o paralelismo em qualquer lugar do plano.
• Uma função escalar CLR pode ser executada em paralelo, desde que não acesse o banco de dados.
• Uma função T-SQL com valor de tabela de várias instruções força uma zona serial em um plano que pode usar paralelismo em outro lugar.
• Uma função T-SQL com valor de tabela embutida é expandida como uma exibição, portanto, não tem efeito direto.

Consulte Forçando um Plano de Execução Paralela e/ou a apresentação de Execução Paralela de Craig Freedman .

Há reclamações sobre UDFs sendo uma caixa preta que deve usar o cursor.

Essas afirmações não são corretas.

Pontos extras para explicar por que o mecanismo força todo o plano a ser serial em vez de apenas o estágio de cálculo do UDF.

Meu entendimento é que as restrições atuais são puramente o resultado de certos detalhes de implementação. Não há razão fundamental para que funções não possam ser executadas usando paralelismo.

Especificamente, as funções escalares do T-SQL são executadas dentro de um contexto separado do T-SQL, o que complica significativamente a operação correta, a coordenação e o desligamento (especialmente no caso de um erro).

Da mesma forma, as variáveis ​​de tabela oferecem suporte a leituras paralelas (mas não a gravações) em geral, mas a variável de tabela exposta por uma função com valor de tabela não é capaz de oferecer suporte a leituras paralelas por motivos específicos da implementação. Você precisaria de alguém com acesso ao código-fonte (e liberdade para compartilhar detalhes) para fornecer uma resposta confiável, receio.

O suporte para UDF paralelo é um recurso razoável a ser solicitado?

Claro, se você puder fazer um caso forte o suficiente. Minha opinião é que o trabalho envolvido seria extenso, então sua proposta teria que atender a um padrão extremamente alto. Por exemplo, uma solicitação relacionada (e muito mais simples) para fornecer funções escalares embutidas tem grande suporte, mas não foi implementada por anos.

Você pode gostar de ler o artigo da Microsoft:

• Froid: Otimização de Programas Imperativos em um Banco de Dados Relacional (pdf)

...que descreve a abordagem que a Microsoft pretende adotar para resolver os problemas de desempenho da função escalar do T-SQL na versão após o SQL Server 2017.

O objetivo do Froid é permitir que os desenvolvedores usem as abstrações de UDFs e procedimentos sem comprometer o desempenho. Froid atinge esse objetivo usando uma nova técnica para converter automaticamente programas imperativos em formas algébricas relacionais equivalentes sempre que possível. Froid modela blocos de código imperativo como expressões relacionais e os combina sistematicamente em uma única expressão usando o operador Apply, permitindo assim que o otimizador de consulta escolha planos de consulta paralelos orientados a conjuntos eficientes.

(grifo meu)

As funções T-SQL escalares embutidas agora são implementadas no SQL Server 2019 .

Como Paul mencionou corretamente em sua resposta, não há razão fundamental para que UDFs escalares não possam ser executadas usando paralelismo. No entanto, além dos desafios de implementação, há outro motivo para forçá-los a serem seriais. O artigo da Froid citado por Paul dá mais informações sobre isso.

Citando o artigo (Seção 2.3):

Atualmente, o SQL Server não usa paralelismo intraconsulta em consultas que invocam UDFs. Os métodos podem ser projetados para atenuar essa limitação, mas apresentam desafios adicionais, como escolher o grau certo de paralelismo para cada invocação da UDF.

Por exemplo, considere uma UDF que chama outras consultas SQL, como a da Figura 1. Cada uma dessas consultas pode usar paralelismo e, portanto, o otimizador não tem como saber como compartilhar threads entre elas, a menos que examine o UDF e decide o grau de paralelismo para cada consulta interna (que pode mudar de uma invocação para outra). Com UDFs aninhados e recursivos, esse problema se torna ainda mais difícil de gerenciar.

A abordagem do Froid, conforme descrito no artigo, não apenas resultará em planos paralelos, mas também agregará muito mais benefícios para consultas com UDFs. Em essência, ele inclui sua solicitação de execução paralela de UDFs.

Atualização: Froid agora está disponível como um recurso de visualização do SQL Server 2019. O recurso é chamado de "Scalar UDF Inlining". Mais detalhes aqui: https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/11/07/introducing-scalar-udf-inlining/

[Divulgação: sou co-autor do artigo Froid]