Il existe plusieurs paramètres pouvant empêcher le planificateur de la requête de générer un plan parallélisé quelles que soient les circonstances. Pour faire en sorte que des plans parallélisés puissent être générés, les paramètres suivants doivent être configurés ainsi :
max_parallel_workers_per_gather doit être
configuré à une valeur strictement positive. Ceci est un cas spécial
du principe plus général qu'il n'y aura pas plus de
workers que le nombre configuré via
max_parallel_workers_per_gather.
dynamic_shared_memory_type doit être configuré à
une valeur autre que none. Les requêtes
parallélisées nécessitent de la mémoire partagée dynamique pour
fournir des données entre les processus participant à la
parallélisation.
De plus, le système ne doit pas fonctionner en mode mono-utilisateur. Comme le système de bases de données entier fonctionne alors avec un seul processus, aucun background worker ne sera disponible.
Même quand il est habituellement possible de générer des plans pour des requêtes parallélisées, le planificateur n'en générera pas pour une requête donnée si une des conditions suivantes est remplie :
La requête écrit des données ou verrouille des lignes de la base. Si une requête contient une opération de modification de données, soit au niveau supérieur, soit dans une CTE, aucun plan parallèle ne peut être généré pour cette requête. Ceci est une limitation de l'implémentation actuelle qui pourrait être supprimée dans une prochaine version.
La requête est susceptible d'être suspendue durant l'exécution. Dans des
situations où le système pense qu'une exécution pourrait être partielle ou
incrémentale, aucun plan parallèle n'est généré.
Par exemple, un curseur créé avec DECLARE CURSOR n'utilisera jamais un plan
parallélisé. De façon similaire, une boucle PL/pgsql de la forme
FOR x IN query LOOP .. END LOOP n'utilisera jamais
un plan parallélisé, car le système est incapable de vérifier que le
code dans la boucle peut s'exécuter en toute sécurité avec une requête
parallélisée.
La requête utilise une fonction marquée PARALLEL UNSAFE (à parallélisation sûre).
La plupart des fonctions systèmes sont PARALLEL SAFE,
mais les fonctions utilisateurs sont marquées PARALLEL UNSAFE
par défaut. Voir la discussion de Section 15.4.
La requête est exécutée à l'intérieur d'une autre requête qui est déjà parallélisée. Par exemple, si une fonction appelée par une requête parallélisée exécute elle-même une requête SQL, celle-ci n'utilisera jamais un plan parallélisé. Ceci est une limitation de l'implémentation actuelle mais il ne serait pas forcément souhaitable de la supprimer car cela pourrait mener à ce que des requêtes simple utilisent un très grand nombre de processus.
Le niveau d'isolation de la transaction est serializable. Ceci est une limitation de l'implémentation actuelle.
Même quand un plan parallélisé est généré pour une requête donnée,
différentes circonstances rendront impossible l'exécution en
parallèle. Si cela arrive, le
leader exécutera tout seul la portion du
plan sous le nœud Gather, pratiquement comme s'il
n'était pas là. Ceci
surviendra si une des conditions suivantes est vérifiée :
Aucun background worker ne peut être obtenu à cause d'une limitation sur le nombre total de background workers, due au paramètre max_worker_processes.
Aucun background worker ne peut être obtenu à cause de la limitation sur le nombre total de background workers qui peuvent être démarrés dans le cadre de requêtes parallèles qui ne peut pas dépasser max_parallel_workers.
Le client envoie un message Execute avec un nombre à récupérer différent de zéro. Voir la discussion sur le protocole de requête étendu. Comme la bibliothèque libpq ne fournit actuellement aucun moyen pour envoyer ce type de message, cela peut seulement survenir suite à l'utilisation d'un client qui ne se base pas sur la libpq. Si cela arrive fréquemment, il pourrait être une bonne idée de configurer max_parallel_workers_per_gather à zéro pour les sessions où cela pourrait survenir, pour éviter de générer des plans de requêtes non optimales s'ils sont exécutés de façon sérialisé.
Une requête préparée est exécutée en utilisant une instruction
CREATE TABLE .. AS EXECUTE ... Cette construction
convertit ce qui serait autrement une opération en lecture seule en
une opération en lecture/écriture, la rendant ainsi inutilisable pour
une requête parallélisée.
Le niveau de transaction est serializable. Cette situation ne doit normalement pas survenir car des plans de requêtes parallélisés ne sont pas générés dans une transaction serializable. Néanmoins, il peut arriver que le niveau d'isolation de la transaction soit modifié après la génération du plan et avant son exécution.
