typos et détails de formulation

postgresql/parallel.xml

@@ -273,10 +273,10 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     À 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 est garantie d'être générée par exactement un des
-    processus coopérant.
+    à 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.
   </para>
 
  <sect2 id="parallel-scans">
@@ -287,7 +287,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     avec les requêtes parallélisées est le parcours séquentiel. 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 divisés parmi les processus coopérant. Les blocs sont
+    relation seront répartis entre les processus coopérants. 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
     réclamer un nouveau bloc.
@@ -298,15 +298,15 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
   <title>Jointures parallélisées</title>
 
   <para>
-    La table doit être jointe à une ou plusieurs autres tables en utilisant
+    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
-    jointure pourrait être tout tupe de plan non parallélisé qui est autrement
-    supporté par le planificateur, en supposant qu'il est sain de l'exécuter
-    avec un <foreignphrase>worker</foreignphrase> parallélisé. Par exemple,
-    cela pourrait être un parcours d'index qui recherche une valeur basée sur
+    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 au
-    complet, ce qui explique pourquoi les jointures par tri ne sont pas
+    <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
@@ -325,7 +325,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 l'agrégat ne peut pas être
     entièrement fait en parallèle, les requêtes impliquant un agrégat sont
-    souvent des candidats excellents pour des requêtes parallélisées parce
+    souvent d'excellents candidats pour des requêtes parallélisées parce
     qu'elles vont typiquement lire beaucoup de lignes tout en en renvoyant peu
     au client. Les requêtes qui renvoient de nombreuses lignes au client sont
     souvent limitées par la vitesse à laquelle le client peut lire les
@@ -336,8 +336,8 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     <productname>PostgreSQL</productname> supporte les agrégats parallélisés
     en agrégeant deux fois. Tout d'abord, chaque processus participant à la
     portion parallélisée de la requête réalise une étape d'agrégation,
-    produisant un resultat partiel pour chaque group dont ce processus est
-    conscient. Ceci est reflété dans le plan avec le n&oelig;ud
+    produisant un resultat partiel pour chaque groupe que ce processus
+    connaît. Ceci est reflété dans le plan avec le n&oelig;ud
     <literal>PartialAggregate</literal>. Ensuite, les résultats partiels sont
     transférés au <foreignphrase>leader</foreignphrase> via le n&oelig;ud
     <literal>Gather</literal>. Enfin, le <foreignphrase>leader</foreignphrase>
@@ -365,14 +365,14 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
   <title>Conseils pour les plans parallélisés</title>
 
   <para>
-    Si une requête qui devrait logiquement utilisé un plan parallélisé ne le
+    Si une requête qu'on s'attend à voir utiliser un plan parallélisé ne le
     fait pas, vous pouvez tenter de réduire <xref
-    linkend="guc-parallel-setup-cost"/> ou <xref linkend="guc-parallel-tuple-
-    cost"/>. Bien sûr, ce plan pourrait devenir plus lent que le plan sériel
-    que le planificateur préfère mais cela ne sera pas toujours le cas. Si
-    vous n'obtenez pas un plan parallélisé même après de très petites valeurs
-    pour ces paramètres (c'est-à-dire après les avoir configuré tous les deux
-    à zéro), il pourrait exister une bonne raison pour laquelle le
+    linkend="guc-parallel-setup-cost"/> ou <xref linkend="guc-parallel-tuple-cost"/>.
+    Bien sûr, ce plan pourrait devenir plus lent que le plan sériel
+    que le planificateur préfèrait 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 (c'est-à-dire après les avoir définies tous les deux
+    à zéro), il pourrait exister une raison pour laquelle le
     planificateur de requêtes est incapable de générer un plan parallélisé
     pour votre requête. Voir <xref linkend="when-can-parallel-query-be-used"/>
     et <xref linkend="parallel-safety"/> pour des informations pouvant
@@ -383,7 +383,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     Lors de l'exécution d'un plan parallélisé, vous pouvez utiliser
     <literal>EXPLAIN (ANALYZE, VERBOSE)</literal> qui affichera des
     statistiques par <foreignphrase>worker</foreignphrase> pour chaque
-    n&oelig;ud du plan. Ceci pourrait être utile pour déterminer si le travail
+    n&oelig;ud du plan. Ce pourrait être utile pour déterminer si le travail
     est correctement distribué entre les n&oelig;uds du plan et plus
     généralement pour comprendre les caractéristiques de performance du plan.
   </para>
@@ -397,8 +397,8 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
   <para>
     Le planificateur classifie les opérations impliquées dans une requête
     comme étant soit <firstterm>sûres à paralléliser</firstterm>,
-    <firstterm>restreint pour la parallélisation</firstterm>, ou <firstterm>à
-    ne pas paralléliser</firstterm>. Une opération sûre à la parallélisation
+    <firstterm>restreintes pour la parallélisation</firstterm>, ou <firstterm>à
+    non sûres à la parallélisation</firstterm>. Une opération sûre à la parallélisation
     est une opération qui n'entre pas en conflit avec l'utilisation d'une
     requête parallélisée. Une opération restreinte à la parallélisation est
     une opération qui ne peut pas être exécutée par un
@@ -456,7 +456,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     un agrégat défini par un utilisateur est sûr, restreint ou non sûr pour la
     parallélisation car cela nécessiterait de pouvoir prédire chaque opération
     réalisée par la fonction. En général, c'est équivalent au
-    <foreignphrase>Halting Problem</foreignphrase> et de ce fait, impossible.
+    Problème de l'arrêt et de ce fait, impossible.
     Même pour des fonctions simples où cela pourrait se faire, nous n'essayons
     pas car cela serait coûteux et sujet à erreurs. À la place, toutes les
     fonctions définies par des utilisateurs sont supposées non sûres à la
@@ -466,21 +466,21 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     <literal>PARALLEL SAFE</literal>, <literal>PARALLEL RESTRICTED</literal>
     ou <literal>PARALLEL UNSAFE</literal> suivant ce qui est approprié. Lors
     de l'utilisation de <xref linkend="sql-createaggregate"/>, l'option
-    <literal>PARALLEL</literal> peut être ajoutée avec
+    <literal>PARALLEL</literal> peut être spécifiée comme 
     <literal>SAFE</literal>, <literal>RESTRICTED</literal> ou
-    <literal>UNSAFE</literal> comme valeur.
+    <literal>UNSAFE</literal>.
   </para>
 
   <para>
     Les fonctions et agrégats doivent être marquées <literal>PARALLEL
-    UNSAFE</literal> s'ils écrivent dans la base, accèdent à des séquences,
+    UNSAFE</literal> si elles écrivent dans la base, accèdent à des séquences,
     modifient l'état de la transaction même temporairement (par exemple, une
-    fonction PL/pgsql qui établit un bloc <literal>EXCEPTION</literal> pour
-    récuéprer des erreurs), ou font des modifications persistentes sur les
+    fonction PL/pgsql qui pose un bloc <literal>EXCEPTION</literal> pour
+    récupérer des erreurs), ou font des modifications persistentes sur les
     paramètres. De façon similaire, les fonctions doivent être marquées
     <literal>PARALLEL RESTRICTED</literal> si elles accèdent à des tables
     temporaires, à l'état de connexion du client, à des curseurs, à des
-    requêtes préparées ou à l'état local du processus serveur, que le système
+    requêtes préparées ou à un quelconque état local du processus serveur que le système
     ne peut pas synchroniser entre les différents
     <foreignphrase>workers</foreignphrase>. Par exemple,
     <literal>setseed</literal> et <literal>random</literal> sont restreints en
@@ -490,13 +490,13 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
   <para>
     En général, si une fonction est marquée comme étant sûre alors qu'elle ne
     l'est pas (et même si elle est seulement restreinte), ou si une fonction
-    est marquée restreinte alors que sa parallélisation n'est pas sûre, cela
-    pourrait être la cause de renvoi d'erreurs ou de mauvaises réponses lors
-    de son utilisation dans une requête parallélisée. Les fonctions en langage C
+    est marquée restreinte alors que sa parallélisation n'est pas sûre, elle
+    pourrait être la cause d'erreurs ou de réponses fausses à
+    l'utilisation dans une requête parallélisée. Les fonctions en langage C
     pourraient en théorie avoir des comportements indéfinis en cas de mauvais
     marquage car le système n'a aucun moyen de se défendre contre du code C
     arbitraire. Cela étant dit, dans la plupart des cas, le résultat ne sera pas
-    pire qu'avec toute autre fonction. En cas de doute, il est probablement mieux
+    pire qu'avec toute autre fonction. En cas de doute, le mieux est probablement
     de marquer les fonctions en tant que <literal>UNSAFE</literal>.
   </para>
 
@@ -506,10 +506,10 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     <foreignphrase>leader</foreignphrase>, par exemple en exécutant une
     requête sur une table non référencée dans la requête, ces verrous seront
     relâchés à la sortie du <foreignphrase>worker</foreignphrase>, et non pas
-    à la fin de la transaction. Si vous écrivez une fonction qui le fait et
-    que cette différence de comportement est important pour vous, marquez ces
+    à la fin de la transaction. Si vous écrivez une fonction qui fait cela et
+    que cette différence de comportement a une importance pour vous, marquez ces
     fonctions comme <literal>PARALLEL RESTRICTED</literal> pour vous assurer
-    qu'elles ne sont exécutées que par le
+    qu'elles ne s'exécutent qu'au sein du
     <foreignphrase>leader</foreignphrase>.
   </para>
 
@@ -519,10 +519,11 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     impliquées dans la requête pour obtenir un plan supérieur. Donc, par
     exemple, si une clause <literal>WHERE</literal> appliquée à une table
     particulière est restreinte à la parallélisation, le planificateur ne
-    considérera pas placer le parcours de cette table sous un n&oelig;ud
-    <literal>Gather</literal>. Dans certains cas, cela serait possible (et
-    peut-être même efficace) d'inclure le parcours de cette table dans la
-    clause <literal>WHERE</literal> pour que cela se passe au-dessus du
+    tentera pas de placer le parcours de cette table sous un n&oelig;ud
+    <literal>Gather</literal>. Dans certains cas, il serait possible 
+    (voire efficace) d'inclure le parcours de cette table dans la
+    partie parallèlisée de la requête et de différer l'évaluation de la 
+    clause <literal>WHERE</literal> afin qu'elle se déroule au-dessus du
     n&oelig;ud <literal>Gather</literal>. Néanmoins, le planificateur ne le
     fait pas.
   </para>