Il est assez bien documenté que les FDU imposent un plan de série global.
Je ne suis pas certain que tout cela soit bien documenté.
- Une fonction scalaire T-SQL empêche le parallélisme n'importe où dans le plan.
- Une fonction scalaire CLR peut être exécutée en parallèle, tant qu'elle n'accède pas à la base de données.
- Une fonction T-SQL multi-instructions de valeur table force une zone série dans un plan qui peut utiliser le parallélisme ailleurs.
- Une fonction T-SQL de table en ligne est développée comme une vue, elle n'a donc aucun effet direct.
Voir Forcer un plan d'exécution parallèle et / ou la présentation Parallel Execution de Craig Freedman .
Certains prétendent que les FDU étant une boîte noire, il faut utiliser le curseur.
Ces affirmations ne sont pas correctes.
Points supplémentaires pour expliquer pourquoi le moteur force l'ensemble du plan à être en série au lieu de simplement l'étape de calcul UDF.
Je crois comprendre que les restrictions actuelles sont uniquement le résultat de certains détails de mise en œuvre. Il n'y a aucune raison fondamentale pour laquelle les fonctions ne peuvent pas être exécutées en utilisant le parallélisme.
Plus précisément, les fonctions scalaires T-SQL s'exécutent dans un contexte T-SQL distinct, ce qui complique considérablement le bon fonctionnement, la coordination et l'arrêt (en particulier en cas d'erreur).
De même, les variables de table prennent en charge les lectures parallèles (mais pas les écritures) en général, mais la variable de table exposée par une fonction table ne peut pas prendre en charge les lectures parallèles pour des raisons spécifiques à l'implémentation. Vous auriez besoin de quelqu'un avec un accès au code source (et la liberté de partager des détails) pour fournir une réponse faisant autorité, je le crains.
La prise en charge d'UDF parallèle est-elle une fonctionnalité raisonnable à demander?
Bien sûr, si vous pouvez faire un dossier suffisamment solide. Mon sentiment est que le travail impliqué serait considérable, donc votre proposition devrait répondre à une barre extrêmement élevée. Par exemple, une demande connexe (et beaucoup plus simple) de fournir des fonctions scalaires en ligne a un grand support, mais a langui sans mise en œuvre depuis des années maintenant.
Vous aimerez peut-être lire le document de Microsoft:
... qui décrit l'approche que Microsoft envisage d'adopter pour résoudre les problèmes de performances des fonctions scalaires T-SQL dans la version après SQL Server 2017.
L'objectif de Froid est de permettre aux développeurs d'utiliser les abstractions des FDU et des procédures sans compromettre les performances. Froid atteint cet objectif en utilisant une nouvelle technique pour convertir automatiquement les programmes impératifs en formes algébriques relationnelles équivalentes chaque fois que possible. Froid modélise des blocs de code impératif en tant qu'expressions relationnelles et les combine systématiquement en une seule expression à l'aide de l'opérateur Apply, permettant ainsi à l'optimiseur de requête de choisir des plans de requête parallèles efficaces orientés ensemble .
(c'est moi qui souligne)
Les fonctions scalaires T-SQL en ligne sont désormais implémentées dans SQL Server 2019 .