Quelques corrections du patch de Christophe

postgresql/parallel.xml

@@ -324,7 +324,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     requête implique une clause <literal>GROUP BY</literal>, un total séparé
     doit être calculé pour chaque groupe. Même si elles ne peuvent être
     entièrement parallélisées, les requêtes avec agrégation sont
-    souvent d'excellentes candidates pour la parallélisation :
+    souvent d'excellentes candidates pour la parallélisation&nbsp;:
     elles lisent généralement beaucoup de lignes tout en en renvoyant peu
     au client. Les requêtes qui renvoient de nombreuses lignes sont
     souvent limitées par la vitesse à laquelle le client peut lire les
@@ -335,7 +335,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     <productname>PostgreSQL</productname> procède à l'agrégation parallélisée
     en agrégeant deux fois. Tout d'abord, chaque processus de la
     partie parallélisée de la requête réalise une étape d'agrégation,
-    produisant un resultat partiel pour chaque groupe qu'il
+    produisant un résultat partiel pour chaque groupe qu'il
     connaît. Ceci se reflète dans le plan par le n&oelig;ud
     <literal>PartialAggregate</literal>. Puis les résultats partiels sont
     transférés au <foreignphrase>leader</foreignphrase> via le n&oelig;ud
@@ -370,10 +370,10 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     Bien sûr, ce plan pourrait bien finir par être plus lent que le plan sériel
     préféré par le planificateur mais ce ne sera pas toujours le cas. Si
     vous n'obtenez pas un plan parallélisé même pour de très petites valeurs
-    de ces paramètres (par exemple après les avoir définies tous les deux
+    de ces paramètres (par exemple après les avoir définis tous les deux
     à zéro), le planificateur a peut-être une bonne raison pour ne pas le faire
     pour votre requête. Voir <xref linkend="when-can-parallel-query-be-used"/>
-    et <xref linkend="parallel-safety"/> pour 
+    et <xref linkend="parallel-safety"/> pour
     des explications sur les causes possibles.
   </para>
 
@@ -514,7 +514,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
   <para>
     Notez que le planificateur de requêtes ne cherche pas à différer
     l'évaluation des fonctions ou agrégats à parallélisation restreinte
-    impliquées dans la requête pour obtenir un meilleur plan. Donc, par
+    impliqués dans la requête pour obtenir un meilleur plan. Donc, par
     exemple, si une clause <literal>WHERE</literal> appliquée à une table
     particulière est à parallélisation restreinte, le planificateur ne
     tentera pas de placer le parcours de cette table sous un n&oelig;ud