Deux nouveaux fichiers traduits

postgresql/pgsurgery.xml

@@ -1,6 +1,4 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- doc/src/sgml/pgsurgery.sgml -->
-
 <sect1 id="pgsurgery" xreflabel="pg_surgery">
  <title>pg_surgery</title>
 
@@ -9,18 +7,20 @@
  </indexterm>
 
  <para>
-  The <filename>pg_surgery</filename> module provides various functions to
-  perform surgery on a damaged relation. These functions are unsafe by design
-  and using them may corrupt (or further corrupt) your database. For example,
-  these functions can easily be used to make a table inconsistent with its
-  own indexes, to cause <literal>UNIQUE</literal> or
-  <literal>FOREIGN KEY</literal> constraint violations, or even to make
-  tuples visible which, when read, will cause a database server crash.
-  They should be used with great caution and only as a last resort.
+  Le module <filename>pg_surgery</filename> fournit différentes fonctions pour
+  réaliser des opérations sur une relation endommagée. Ces fonctions sont
+  dangereuses de par leur concept et les utiliser pourrait corrompre
+  (ou corrompre encore plus) votre bases de données. Par exemple, ces
+  fonctions peuvent facilement être utilisées pour rendre une table
+  incohérente avec ses propres index, causant des violations de contraintes
+  <literal>UNIQUE</literal> ou <literal>FOREIGN KEY</literal>, voire même de
+  rendre des lignes visibles qui, lorsqu'elles sont lues, vont causer un
+  crash du serveur de bases de données. Vous devez faire très attention en
+  les utilisant. Leur utilisation doit rester pour les cas désespérés.
  </para>
 
  <sect2>
-  <title>Functions</title>
+  <title>Fonctions</title>
 
   <variablelist>
    <varlistentry>
@@ -30,10 +30,10 @@
 
     <listitem>
      <para>
-      <function>heap_force_kill</function> marks <quote>used</quote> line
-      pointers as <quote>dead</quote> without examining the tuples. The
-      intended use of this function is to forcibly remove tuples that are not
-      otherwise accessible. For example:
+      <function>heap_force_kill</function> marque les pointeurs de lignes
+      <quote>utilisées</quote> comme <quote>mortes</quote> sans examiner les
+      lignes. Le but de cette fonction est de forcer la suppression de lignes
+      autrement inaccessibles. Par exemple&nbsp;:
 <programlisting>
 test=&gt; select * from t1 where ctid = '(0, 1)';
 ERROR:  could not access status of transaction 4007513275
@@ -60,12 +60,12 @@ test=# select * from t1 where ctid = '(0, 1)';
 
     <listitem>
      <para>
-      <function>heap_force_freeze</function> marks tuples as frozen without
-      examining the tuple data. The intended use of this function is to
-      make accessible tuples which are inaccessible due to corrupted
-      visibility information, or which prevent the table from being
-      successfully vacuumed due to corrupted visibility information.
-      For example:
+      <function>heap_force_freeze</function> marque les lignes comme gelées
+      sans examiner les données des lignes. Le but de cette fonction est de
+      rendre accessibles des lignes qui étaient auparavant inaccessibles à
+      cause de la corruption des informations de visibilité, ou qui
+      empêchaient la réussite d'un vacuum sur la table à cause de corruption
+      sur les informations de visibilité. Par exemple&nbsp;:
 <programlisting>
 test=&gt; vacuum t1;
 ERROR:  found xmin 507 from before relfrozenxid 515
@@ -98,7 +98,7 @@ test=# select ctid from t1 where xmin = 2;
  </sect2>
 
  <sect2>
-  <title>Authors</title>
+  <title>Auteurs</title>
 
   <para>
    Ashutosh Sharma <email>ashu.coek88@gmail.com</email>

postgresql/ref/create_statistics.xml

@@ -1,9 +1,4 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!--
-doc/src/sgml/ref/create_statistics.sgml
-PostgreSQL documentation
--->
-
 <refentry id="sql-createstatistics">
  <indexterm zone="sql-createstatistics">
   <primary>CREATE STATISTICS</primary>
@@ -46,21 +41,22 @@ CREATE STATISTICS [ IF NOT EXISTS ] <replaceable class="parameter">nom_statistiq
   </para>
 
   <para>
-   The <command>CREATE STATISTICS</command> command has two basic forms. The
-   first form allows univariate statistics for a single expression to be
-   collected, providing benefits similar to an expression index without the
-   overhead of index maintenance.  This form does not allow the statistics
-   kind to be specified, since the various statistics kinds refer only to
-   multivariate statistics.  The second form of the command allows
-   multivariate statistics on multiple columns and/or expressions to be
-   collected, optionally specifying which statistics kinds to include.  This
-   form will also automatically cause univariate statistics to be collected on
-   any expressions included in the list.
+   La commande <command>CREATE STATISTICS</command> a deux formes basiques. La
+   première forme autorise des statistiques à une variable pour une simple
+   expression à récupérer, fournissant des bénéfices similaires à un index
+   avec expression sans le surcoût de maintenance de l'index. Cette forme ne
+   permet pas d'indiquer le type de statistiques car les différents types de
+   statistiques sont uniquement pour les statistiques avec au moins deux
+   variables. La seconde forme de la commande permet la récupération de
+   statistiques sur plusieurs colonnes et/ou expressions, en indiquant
+   optionnellement les types de statistiques à inclure. Cette forme causera
+   aussi la récupération de statistiques à une variable sur toute expression
+   incluse dans la liste.
   </para>
 
   <para>
    Si un nom de schéma est donné (par exemple, <literal>CREATE STATISTICS
-    monschema.mastat ...</literal>) alors l'objet statistiques est crée dans le
+   monschema.mastat ...</literal>) alors l'objet statistiques est crée dans le
    schéma spécifié. Autrement, il sera crée dans le schéma courant. Le nom de
    l'objet statistiques doit être différent du nom de tous les autres objets
    statistiques dans le même schéma.
@@ -98,16 +94,16 @@ CREATE STATISTICS [ IF NOT EXISTS ] <replaceable class="parameter">nom_statistiq
     <term><replaceable class="parameter">type_statistique</replaceable></term>
     <listitem>
      <para>
-      Un type de statistique multivarié devant être calculé dans cet objet statistiques.
-      Les types actuellement supportés sont
+      Un type de statistique multivarié devant être calculé dans cet objet
+      statistiques. Les types actuellement supportés sont
       <literal>ndistinct</literal>, qui active des statistiques n-distinct,
-      <literal>dependencies</literal> qui active des statistiques de dépendances
-      fonctionnelles, et <literal>mcv</literal> qui active les listes
-      des valeurs les plus fréquentes.
-      Si cette clause est omise, tous les types statistiques supportés sont
-      inclus dans l'objet statistique. Univariate expression statistics are
-      built automatically if the statistics definition includes any complex
-      expressions rather than just simple column references.
+      <literal>dependencies</literal> qui active des statistiques de
+      dépendances fonctionnelles, et <literal>mcv</literal> qui active les
+      listes des valeurs les plus fréquentes. Si cette clause est omise, tous
+      les types statistiques supportés sont inclus dans l'objet statistique.
+      Les statistiques d'expression sur une variable sont construits
+      automatiquement si la définition des statistiques inclue des
+      expressions complexes plutôt que de simples références de colonnes.
       Pour plus d'informations, voir <xref linkend="planner-stats-extended"/>
       et <xref linkend="multivariate-statistics-examples"/>.
      </para>
@@ -119,10 +115,10 @@ CREATE STATISTICS [ IF NOT EXISTS ] <replaceable class="parameter">nom_statistiq
     <listitem>
      <para>
       Le nom d'une colonne de la table devant être couverte par les
-      statistiques calculées.
-      This is only allowed when building multivariate statistics.  At least
-      two column names or expressions must be specified, and their order is
-      not significant.
+      statistiques calculées. Ceci est seulement autorisé pour construire des
+      statistiques sur plusieurs variables. Au moins deux noms de colonne ou
+      expressions doivent être indiqués, mais leur ordre n'est pas
+      significatif.
      </para>
     </listitem>
    </varlistentry>
@@ -131,11 +127,12 @@ CREATE STATISTICS [ IF NOT EXISTS ] <replaceable class="parameter">nom_statistiq
     <term><replaceable class="parameter">expression</replaceable></term>
     <listitem>
      <para>
-      An expression to be covered by the computed statistics.  This may be
-      used to build univariate statistics on a single expression, or as part
-      of a list of multiple column names and/or expressions to build
-      multivariate statistics.  In the latter case, separate univariate
-      statistics are built automatically for each expression in the list.
+      Une expression couverte par les statistiques calculées. Ceci pourrait
+      être utilisé pour construire des statistiques univariées sur une seule
+      expression, ou faire partie d'une liste de plusieurs noms de colonnes
+      et/ou expressions pour construire des statistiques multivariées. Dans
+      ce dernier cas, les statistiques univariées séparées sont construites
+      automatiquement pour chaque expression de la liste.
      </para>
     </listitem>
    </varlistentry>
@@ -163,10 +160,11 @@ CREATE STATISTICS [ IF NOT EXISTS ] <replaceable class="parameter">nom_statistiq
   </para>
 
   <para>
-   Expression statistics are per-expression and are similar to creating an
-   index on the expression, except that they avoid the overhead of index
-   maintenance. Expression statistics are built automatically for each
-   expression in the statistics object definition.
+   Les statistiques d'expression sont par expression et sont similaires à
+   créer un index sur l'expression, sauf qu'elles évitent le surcoût de
+   maintenance de l'index. Les statistiques d'expression sont construites
+   automatiquement pour chaque expression dans la définition de l'objet
+   statistique.
   </para>
  </refsect1>
 
@@ -178,7 +176,7 @@ CREATE STATISTICS [ IF NOT EXISTS ] <replaceable class="parameter">nom_statistiq
    fonctionnellement dépendantes, c'est-à-dire que la connaissance de la valeur
    de la première colonne est suffisante pour déterminer la valeur de l'autre
    colonne. Ensuite des statistiques de dépendances fonctionnelles sont
-   construites sur ces colonnes :
+   construites sur ces colonnes&nbsp;:
 
    <programlisting>
 CREATE TABLE t1 (
@@ -244,13 +242,15 @@ EXPLAIN ANALYZE SELECT * FROM t2 WHERE (a = 1) AND (b = 2);
   </para>
 
   <para>
-   Create table <structname>t3</structname> with a single timestamp column,
-   and run queries using expressions on that column.  Without extended
-   statistics, the planner has no information about the data distribution for
-   the expressions, and uses default estimates.  The planner also does not
-   realize that the value of the date truncated to the month is fully
-   determined by the value of the date truncated to the day. Then expression
-   and ndistinct statistics are built on those two expressions:
+   Créer une table <structname>t3</structname> avec une seule colonne de type
+   timestamp, et exécuter des requêtes en utilisant des expressions sur cette
+   colonne. Sans les statistiques étendues, le planificateur n'a pas
+   d'information sur la distribution des données pour les expressions, et
+   utilise les estimations par défaut. Le planificateyr ne réalise pas non
+   plus que la valeur de la date tronquée au mois est complètement déterminée
+   par la valeur de la date tronquée au jour. De ce fait, des statistiques
+   sur l'expression et sur ndistinct sont construites sur ces deux
+   expressions&nbsp;:
 
 <programlisting>
 CREATE TABLE t3 (
@@ -263,7 +263,7 @@ INSERT INTO t3 SELECT i FROM generate_series('2020-01-01'::timestamp,
 
 ANALYZE t3;
 
--- the number of matching rows will be drastically underestimated:
+-- le nombre de lignes correspondantes va être fortement sous-estimé :
 EXPLAIN ANALYZE SELECT * FROM t3
   WHERE date_trunc('month', a) = '2020-01-01'::timestamp;
 
@@ -274,13 +274,13 @@ EXPLAIN ANALYZE SELECT * FROM t3
 EXPLAIN ANALYZE SELECT date_trunc('month', a), date_trunc('day', a)
    FROM t3 GROUP BY 1, 2;
 
--- build ndistinct statistics on the pair of expressions (per-expression
--- statistics are built automatically)
+-- construction de statistiques ndistinct sur la paire d'expressions (des statistiques
+-- par expression sont construites automatiquement)
 CREATE STATISTICS s3 (ndistinct) ON date_trunc('month', a), date_trunc('day', a) FROM t3;
 
 ANALYZE t3;
 
--- now the row count estimates are more accurate:
+-- maintenant les estimations de nombre de lignes sont plus précises :
 EXPLAIN ANALYZE SELECT * FROM t3
   WHERE date_trunc('month', a) = '2020-01-01'::timestamp;
 
@@ -292,21 +292,24 @@ EXPLAIN ANALYZE SELECT date_trunc('month', a), date_trunc('day', a)
    FROM t3 GROUP BY 1, 2;
 </programlisting>
 
-   Without expression and ndistinct statistics, the planner has no information
-   about the number of distinct values for the expressions, and has to rely
-   on default estimates. The equality and range conditions are assumed to have
-   0.5% selectivity, and the number of distinct values in the expression is
-   assumed to be the same as for the column (i.e. unique). This results in a
-   significant underestimate of the row count in the first two queries. Moreover,
-   the planner has no information about the relationship between the expressions,
-   so it assumes the two <literal>WHERE</literal> and <literal>GROUP BY</literal>
-   conditions are independent, and multiplies their selectivities together to
-   arrive at a severe overestimate of the group count in the aggregate query.
-   This is further exacerbated by the lack of accurate statistics for the
-   expressions, forcing the planner to use a default ndistinct estimate for the
-   expression derived from ndistinct for the column. With such statistics, the
-   planner recognizes that the conditions are correlated, and arrives at much
-   more accurate estimates.
+   Sans statistiques sur l'expression et le ndistinct, le planificateur n'a
+   pas d'informations sur le nombre de valeurs distinctes pour les
+   expressions, et doit se baser sur les estimations par défaut. Les
+   conditions d'égalité et d'intervalle sont supposées avoir une sélectivité
+   de 0,5%, et le nombre de valeurs distinctes dans l'expression est supposé
+   être le même que pour la colonne (i.e. unique). Ceci résulte en une
+   sous-estimation significative du nombre de lignes pour les deux premières
+   requêtes. De plus, le planificateur ne connaît pas la relation entre les
+   expressions, donc il suppose que les deux conditions du
+   <literal>WHERE</literal> et la condition du <literal>GROUP BY</literal>
+   sont indépendentes, et multiplie leurs sélectivités ensemble pour arriver
+   à une sous-estimation sévère du nombre de groupes dans la requête
+   d'agrégat. Ceci est encore plus exacerbé par le manque de statistiques
+   précises sur les expressions, forçant le planificateur à utiliser une
+   estimation par défaut du ndistinct pour l'expression dérivée du ndistinct
+   pour la colonne. Avec de telles statistiques, le planificateur reconnaît
+   que les conditions sont corrélées, et arrive à des estimations bien plus
+   précises.
   </para>
 
  </refsect1>