Correction de quelques typos

postgresql/planstats.xml

@@ -464,7 +464,7 @@ rows = (outer_cardinality * inner_cardinality) * selectivity
    <para>
     La corrélation multivariée peut être démontrée avec un jeu de test très
     simple &mdash; une table avec deux colonnes, chacune contenant les même
-    valeurs :
+    valeurs&nbsp;:
 
 <programlisting>
 CREATE TABLE t (a INT, b INT);
@@ -475,7 +475,7 @@ ANALYZE t;
     Comme expliqué dans <xref linkend="planner-stats"/>, l'optimiseur peut
     déterminer la cardinalité de <structname>t</structname> en utilisant le
     nombre de pages et de lignes obtenues dans
-    <structname>pg_class</structname> :
+    <structname>pg_class</structname>&nbsp;:
 
 <programlisting>
 SELECT relpages, reltuples FROM pg_class WHERE relname = 't';
@@ -491,7 +491,7 @@ SELECT relpages, reltuples FROM pg_class WHERE relname = 't';
 
    <para>
     L'exemple suivant montre le résultat de l'estimation d'une conditino
-    <literal>WHERE</literal> sur la colonne <structfield>a</structfield> :
+    <literal>WHERE</literal> sur la colonne <structfield>a</structfield>&nbsp;:
 
 <programlisting>
 EXPLAIN (ANALYZE, TIMING OFF) SELECT * FROM t WHERE a = 1;
@@ -502,14 +502,14 @@ EXPLAIN (ANALYZE, TIMING OFF) SELECT * FROM t WHERE a = 1;
    Rows Removed by Filter: 9900
 </programlisting>
 
-    L'optimiseur examine la condtion et détermine que la sélectivité de cette
-    clause est d' 1%.  En comparant cette estimation avec le nombre de ligne
-    réelle, on voit que l'estimaation est très précise (elle est en fait exact,
+    L'optimiseur examine la condition et détermine que la sélectivité de cette
+    clause est de 1%.  En comparant cette estimation avec le nombre de lignes
+    réel, on voit que l'estimation est très précise (elle est en fait exacte
     car la table est très petite).  En changeant la clause
     <literal>WHERE</literal> pour utiliser la colonne
     <structfield>b</structfield>, un plan identique est généré.  Mais observons
     ce qui arrive si nous appliquons la même condition sur chacune des
-    colonnes, en les combinant avec <literal>AND</literal> :
+    colonnes, en les combinant avec <literal>AND</literal>&nbsp;:
 
 <programlisting>
 EXPLAIN (ANALYZE, TIMING OFF) SELECT * FROM t WHERE a = 1 AND b = 1;
@@ -522,7 +522,7 @@ EXPLAIN (ANALYZE, TIMING OFF) SELECT * FROM t WHERE a = 1 AND b = 1;
 
     L'optimiseur estime la sélectivité pour chaque condition individuellement,
     en arrivant à la même estimation d'1% comme au dessus.  Puis il part du
-    principe que les conditions sont indépendantes, et multiple donc leurs
+    principe que les conditions sont indépendantes, et multiplie donc leurs
     sélectivité, produisant une estimation de sélectivité finale d'uniquement
     0.01%.  C'est une sous estimation importante, puisque le nombre réel de
     lignes correspondant aux conditions (100) est d'un ordre de grandeur deux
@@ -531,8 +531,8 @@ EXPLAIN (ANALYZE, TIMING OFF) SELECT * FROM t WHERE a = 1 AND b = 1;
 
    <para>
     Ce problème peut être corrigé en créant un objet statistiques qui demandera
-    à <command>ANALYZE</command> de calculer des statistiques multivariée de
-    dépendances fonctionnelles sur les deux colonnes :
+    à <command>ANALYZE</command> de calculer des statistiques multivariées de
+    dépendances fonctionnelles sur les deux colonnes&nbsp;:
 
 <programlisting>
 CREATE STATISTICS stts (dependencies) ON a, b FROM t;
@@ -555,7 +555,7 @@ EXPLAIN (ANALYZE, TIMING OFF) SELECT * FROM t WHERE a = 1 AND b = 1;
     ensemble de plusieurs colonnes, tel que le nombre de groupes qu'une clause
     <command>GROUP BY</command> générerait.  Quand <command>GROUP BY</command>
     liste une seule colonne, l'estimation n-distinct (qui est visible comme le
-    nombre de lignes estimé par le nœud HashAggregate) est très précis :
+    nombre de lignes estimé par le nœud HashAggregate) est très précis&nbsp;:
 <programlisting>
 EXPLAIN (ANALYZE, TIMING OFF) SELECT COUNT(*) FROM t GROUP BY a;
                                        QUERY PLAN                                        
@@ -566,7 +566,7 @@ EXPLAIN (ANALYZE, TIMING OFF) SELECT COUNT(*) FROM t GROUP BY a;
 </programlisting>
     Mais sans statistiques multivariées, l'estimation du nombre de groupe dans
     une requête ayant deux colonnes dans le <command>GROUP BY</command>, comme
-    dans l'exemple suivant, est faux d'un ordre de grandeur :
+    dans l'exemple suivant, est faux d'un ordre de grandeur&nbsp;:
 <programlisting>
 EXPLAIN (ANALYZE, TIMING OFF) SELECT COUNT(*) FROM t GROUP BY a, b;
                                        QUERY PLAN                                        
@@ -576,7 +576,7 @@ EXPLAIN (ANALYZE, TIMING OFF) SELECT COUNT(*) FROM t GROUP BY a, b;
    -&gt;  Seq Scan on t  (cost=0.00..145.00 rows=10000 width=8) (actual rows=10000 loops=1)
 </programlisting>
     En redéfinissant l'objet statistiques pour inclure un nombre n-distinct
-    pour les deux colonnes, l'estimation est bien améliorée :
+    pour les deux colonnes, l'estimation est bien améliorée&nbsp;:
 <programlisting>
 DROP STATISTICS stts;
 CREATE STATISTICS stts (dependencies, ndistinct) ON a, b FROM t;