Relecture parallel.xml - 15.3 à 15.3.2

Détails de formulation.
Il y a pas mal de verbes au futur dans la VO qui à mon sens ne devraient pas l'être.

postgresql/parallel.xml

@@ -264,32 +264,32 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
 
   <para>
     Comme chaque <foreignphrase>worker</foreignphrase> exécute la portion
-    parallélisée du plan jusqu'à sa fin, il n'est pas possible de prendre un
-    plan de requête ordiniaire et de l'exécuter en utilisant plusieurs
+    parallélisée du plan jusqu'à la fin, il n'est pas possible de prendre un
+    plan de requête ordinaire et de l'exécuter en utilisant plusieurs
     <foreignphrase>workers</foreignphrase>. Chaque
-    <foreignphrase>worker</foreignphrase> produira une copie complète de
-    l'ensemble de résultats en sortie, donc la requête  ne s'exécuterait pas
-    plus rapidement que normalement, mais produirait des résultats incorrects.
+    <foreignphrase>worker</foreignphrase> produirait une copie complète du
+    jeu de résultats, donc la requête  ne s'exécuterait pas
+    plus rapidement qu'à la normale, et produirait des résultats incorrects.
     À la place, la portion parallélisée du plan doit être ce qui est connu en
     interne par l'optimiseur de requêtes comme un <firstterm>plan
     partiel</firstterm>&nbsp;; c'est-à-dire qu'il doit être construit de façon
-    à ce que chaque processus qui exécute le plan génèrera seulement un
-    sous-ensemble des lignes en résultat d'une telle façon que chaque ligne
-    nécessaire en sortie a la garantie d'être générée par exactement un des
-    processus coopérants.
+    à ce que chaque processus exécutant le plan génère seulement un
+    sous-ensemble des lignes en sortie et que chacune
+    ait la garantie d'être générée par exactement un des
+    processus participants.
   </para>
 
  <sect2 id="parallel-scans">
   <title>Parcours parallélisées</title>
 
   <para>
-    Actuellement, le seul type de parcours qui a été modifié pour fonctionner
-    avec les requêtes parallélisées est le parcours séquentiel. De ce fait, la
+    Actuellement, le seul type de parcours qui ait été modifié pour fonctionner
+    avec des requêtes parallélisées est le parcours séquentiel (<literal>Seq Scan</literal>). De ce fait, la
     table en question dans un plan parallélisé sera toujours parcourue en
-    utilisant un <literal>Parallel Seq Scan</literal>.  Les blocs de la
-    relation seront répartis entre les processus coopérants. Les blocs sont
+    utilisant un <literal>Parallel Seq Scan</literal>. Les blocs de la
+    relation sont répartis entre les processus participants. Les blocs sont
     gérés un par un, donc cet accès à la relation reste séquentiel. Chaque
-    processus visitera chaque ligne du bloc qui lui est assigné avant de
+    processus visite chaque ligne du bloc qui lui est assigné avant de
     réclamer un nouveau bloc.
   </para>
  </sect2>
@@ -299,18 +299,20 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
 
   <para>
     La table peut être jointe à une ou plusieurs autres tables en utilisant
-    une boucle imbriquée ou une jointure par hachage. Le côté externe de la
+    une boucle imbriquée (<foreignphrase>nested loop</foreignphrase>
+    ou une jointure par hachage (<foreignphrase>hash join</foreignphrase> ). 
+    Le côté externe de la
     jointure peut être n'importe quel type de plan non parallélisé
     supporté par le planificateur par ailleurs, pourvu qu'il soit sûr de l'exécuter
     dans un <foreignphrase>worker</foreignphrase> parallélisé. Par exemple,
     ce peut être un parcours d'index recherchant une valeur basée sur
     une colonne prise dans la table interne. Chaque
     <foreignphrase>worker</foreignphrase> exécutera le côté externe du plan en
-    totalité, ce qui explique pourquoi les jointures par tri ne sont pas
-    supportées ici. Le côté externe d'une jointure par tri impliquera souvent
-    le tri complet de la table interne. Même si cela implique un index, il y a
-    peu de chance que ce soit efficace d'avoir plusieurs processus réalisant
-    chacun un parcours d'index complet de la table interne.
+    totalité, ce qui explique pourquoi les jointures par tri (<foreignphrase>merge join</foreignphrase>) ne sont pas
+    supportées ici. Le côté externe d'une jointure par tri implique souvent
+    le tri complet de la table interne&nbsp;; même avec un index, 
+    plusieurs processus réalisant
+    chacun un parcours d'index complet de la table intérieure est rarement efficace.
   </para>
  </sect2>