Relecture du chapitre sur les requêtes parallélisées

postgresql/parallel.xml

@@ -19,7 +19,7 @@
    due à une requête parallélisée est souvent très significative. Beaucoup de
    ces requêtes peuvent s'exécuter au moins deux fois plus rapidement grâce à
    la parallélisation, et certaines requêtes quatre fois
-   voire plus. Les requêtes touchant à une grande quantité de données mais
+   voire plus. Les requêtes touchant à une grande quantité de données, mais
    ne retournant que quelques lignes à l'utilisateur sont généralement celles
    qui bénéficient le plus de cette fonctionnalité. Ce chapitre explique
    quelques détails sur le fonctionnement des requêtes parallélisées et dans
@@ -130,7 +130,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
 
   <para>
     Il existe plusieurs paramètres pouvant empêcher le planificateur
-    de la requête de générer un plan parallélisé quelque soient les
+    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&nbsp;:
   </para>
@@ -183,7 +183,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
         linkend="sql-declare">DECLARE CURSOR</link> n'utilisera jamais un plan
         parallélisé. De façon similaire, une boucle PL/pgSQL de la forme
         <literal>FOR x IN query LOOP .. END LOOP</literal> n'utilisera jamais
-        un plan parallélisé car le système est incapable de vérifier que le
+        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.
       </para>
@@ -207,8 +207,8 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
         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 qu'une seule requête
+        l'implémentation actuelle, mais il ne serait pas forcément souhaitable de la
+        supprimer, car cela pourrait mener à ce qu'une seule requête
         utilise un très grand nombre de processus.
       </para>
     </listitem>
@@ -251,11 +251,11 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
         Comme la bibliothèque <link linkend="libpq">libpq</link> ne fournit
         actuellement aucun moyen pour envoyer ce type de message, cela ne peut
         survenir qu'en utilisant un client qui ne se base
-        pas sur la libpq. Si cela arrive fréquemment, il pourrait être une
+        pas sur la libpq. Si cela arrive fréquemment, ce pourrait être une
         bonne idée de configurer <xref
         linkend="guc-max-parallel-workers-per-gather"/> à zéro pour les
         sessions concernées, pour éviter de générer des plans
-        de requêtes non optimales s'ils sont exécutés de façon sérialisé.
+        de requêtes non optimaux s'ils sont exécutés de façon sérialisée.
       </para>
     </listitem>
   </itemizedlist>
@@ -282,7 +282,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
   </para>
 
  <sect2 id="parallel-scans">
-  <title>Parcours parallélisées</title>
+  <title>Parcours parallélisés</title>
 
   <para>
     Les types suivants de parcours de table sont actuellement
@@ -369,7 +369,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
         de la table de hachage. Cela peut être inefficace si cette table est
         grande ou le plan coûteux. Dans une <emphasis>jointure par hachage
         parallélisée</emphasis>, le côté interne est un <emphasis>hachage
-        parallèle</emphasis> qui divise le travail entre une table de hachage
+        parallèle</emphasis> qui divise le travail sur une table de hachage
         partagée entre les processus participants.
       </para>
     </listitem>
@@ -387,7 +387,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     <literal>PartialAggregate</literal>. Puis les résultats partiels sont
     transférés au <foreignphrase>leader</foreignphrase> via le n&oelig;ud
     <literal>Gather</literal> ou <literal>Gather Merge</literal>. Enfin, le
-    <foreignphrase>leader</foreignphrase> ré-agrège les résultats partiels de
+    <foreignphrase>leader</foreignphrase> réagrège les résultats partiels de
     tous les
     <foreignphrase>workers</foreignphrase> pour produire le résultat final.
     Ceci apparaît dans le plan sous la forme d'un n&oelig;ud
@@ -398,14 +398,14 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     Comme le n&oelig;ud <literal>Finalize Aggregate</literal> s'exécute sur le
     processus leader, les requêtes produisant un nombre relativement important
     de groupes en comparaison du nombre de lignes en entrée apparaîtront comme
-    moins favorable au planificateur de requêtes. Par exemple, dans le pire
+    moins favorables au planificateur de requêtes. Par exemple, dans le pire
     scénario, le nombre de groupes vus par le n&oelig;ud <literal>Finalize
     Aggregate</literal> pourrait être aussi grand que le nombre de lignes en
     entrée traitées par les processus workers à l'étape
     <literal>Partial Aggregate</literal>. Dans de tels cas, au niveau des
     performances il n'y a clairement aucun intérêt à utiliser
     l'agrégation parallélisée. Le planificateur de requêtes prend cela en
-    compte lors du processus de planification et a peu de chance de choisir un
+    compte lors du processus de planification et a peu de chances de choisir un
     agrégat parallélisé sur ce scénario.
    </para>
 
@@ -430,7 +430,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
 
    <para>
      Quand <productname>PostgreSQL</productname> a besoin de combiner des
-     lignes de plusieurs sources dans un seul ensemble de résultat, il
+     lignes de plusieurs sources dans un seul ensemble de résultats, il
      utilise un nœud <literal>Append</literal> ou <literal>MergeAppend</literal>.
      Cela arrive souvent en implémentant un <literal>UNION ALL</literal> ou en
      parcourant une table partitionnée. Ces nœuds peuvent être utilisés dans des
@@ -575,12 +575,12 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
 
   <para>
     Le planificateur ne peut pas déterminer automatiquement si une fonction ou
-    un agrégat défini par un utilisateur est à parallélisation sûre,
+    un agrégat définis par un utilisateur est à parallélisation sûre,
     restreinte ou non sûre, car cela nécessiterait de pouvoir prédire
     chaque opération réalisable par la fonction. En général, c'est équivalent au
     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 ce serait coûteux et sujet à erreurs. À la place, toutes les
+    pas, car ce serait coûteux et sujet à erreurs. À la place, toutes les
     fonctions définies par des utilisateurs sont supposées à parallélisation non sûre
     sauf indication contraire. Lors de l'utilisation des
     instructions <xref linkend="sql-createfunction"/> et <xref
@@ -598,7 +598,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     UNSAFE</literal> s'ils é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 définit un bloc <literal>EXCEPTION</literal> pour
-    récupérer des erreurs), ou font des modifications persistentes sur les
+    récupérer des erreurs), ou font des modifications persistantes 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
@@ -616,7 +616,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     peut être cause d'erreurs ou de réponses fausses lors de
     l'utilisation dans une requête parallélisée. Les fonctions en langage C
     peuvent 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
+    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, le mieux est probablement
     de marquer les fonctions en tant que <literal>UNSAFE</literal>.
@@ -644,7 +644,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     tentera pas de placer le parcours de cette table dans une portion
     parallélisée du plan. 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
+    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.