Traduction de pgstatstatements.xml

postgresql/pgstatstatements.xml

@@ -68,7 +68,7 @@
       <entry><structfield>queryid</structfield></entry>
       <entry><type>bigint</type></entry>
       <entry></entry>
-      <entry>Internal hash code, computed from the statement's parse tree</entry>
+      <entry>Code de hachage interne, calculé à partir de l'arbre d'analyse de la requête.</entry>
      </row>
 
      <row>
@@ -234,10 +234,10 @@
    il est composé du texte de la première requête dont la valeur de hachage
    correspond à l'entrée en question. Toutefois, lorsqu'une valeur constante a
    été ignorée de manière à faire correspondre une requête à cette première
-   requête, la constante est remplacée par <literal>?</literal>. The rest of the query
-   text is that of the first query that had the particular
-   <structfield>queryid</structfield> hash value associated with the
-   <structname>pg_stat_statements</structname> entry.
+   requête, la constante est remplacée par <literal>?</literal>.  Le reste du
+   texte de la requête est celui de la première requête qui a eu la valeur
+   particulière de hachage <structfield>queryid</structfield> associée à
+   l'entrée de <structname>pg_stat_statements</structname>.
   </para>
 
   <para>
@@ -251,43 +251,46 @@
   </para>
 
   <para>
-   Since the <structfield>queryid</structfield> hash value is computed on the
-   post-parse-analysis representation of the queries, the opposite is
-   also possible: queries with identical texts might appear as
-   separate entries, if they have different meanings as a result of
-   factors such as different <varname>search_path</varname> settings.
+   Puisque la valeur de hachage <structfield>queryid</structfield> est calculée
+   sur la représentation de la requête après analyse, l'inverse est également
+   possible&nbsp;: des requêtes avec un texte identique peuvent apparaître
+   comme des entrées séparées, si elles ont des significations différentes en
+   fonction de facteurs externes, comme des réglages de
+   <varname>search_path</varname> différents.
   </para>
 
   <para>
-   Consumers of <literal>pg_stat_statements</literal> may wish to use
-   <structfield>queryid</structfield> (perhaps in combination with
-   <structfield>dbid</structfield> and <structfield>userid</structfield>) as a more stable
-   and reliable identifier for each entry than its query text.
-   However, it is important to understand that there are only limited
-   guarantees around the stability of the <structfield>queryid</structfield> hash
-   value.  Since the identifier is derived from the
-   post-parse-analysis tree, its value is a function of, among other
-   things, the internal object identifiers appearing in this representation.
-   This has some counterintuitive implications.  For example,
-   <literal>pg_stat_statements</literal> will consider two apparently-identical
-   queries to be distinct, if they reference a table that was dropped
-   and recreated between the executions of the two queries.
-   The hashing process is also sensitive to differences in
-   machine architecture and other facets of the platform.
-   Furthermore, it is not safe to assume that <structfield>queryid</structfield>
-   will be stable across major versions of <productname>PostgreSQL</productname>.
+   Les programmes utilisant <literal>pg_stat_statements</literal> pourraient
+   préférer utiliser <structfield>queryid</structfield> (peut-être en
+   association avec <structfield>dbid</structfield> et <structfield>userid</structfield>)
+   pour disposer d'un identifiant plus stable et plus sûr pour chaque entrée
+   plutôt que le texte de la requête.  Cependant, il est important de
+   comprendre qu'il n'y a qu'une garantie limitée sur la stabilité de la valeur
+   de hachage de <structfield>queryid</structfield>.  Puisque l'identifiant est
+   dérivé de l'arbre après analyse, sa valeur est une fonction, entre autres
+   choses, des identifiants d'objet interne apparaissant dans cette
+   représentation.  Cela a des implications paradoxales.  Par exemple,
+   <literal>pg_stat_statements</literal> considérera deux requêtes apparemment
+   identiques comme distinctes, si elles référencent une table qui a été
+   supprimée et recréée entre l'exécution de ces deux requêtes.  Le processus de
+   hachage est également sensible aux différences d'architecture des machines
+   ainsi que d'autres facettes de la plateforme.  De plus, il n'est pas sûr de
+   partir du principe que <structfield>queryid</structfield> restera stable
+   entre des versions majeures de <productname>PostgreSQL</productname>.
   </para>
 
   <para>
-   As a rule of thumb, <structfield>queryid</structfield> values can be assumed to be
-   stable and comparable only so long as the underlying server version and
-   catalog metadata details stay exactly the same.  Two servers
-   participating in replication based on physical WAL replay can be expected
-   to have identical <structfield>queryid</structfield> values for the same query.
-   However, logical replication schemes do not promise to keep replicas
-   identical in all relevant details, so <structfield>queryid</structfield> will
-   not be a useful identifier for accumulating costs across a set of logical
-   replicas.  If in doubt, direct testing is recommended.
+   De manière générale, on peut supposer que les valeurs de
+   <structfield>queryid</structfield> sont stables et comparables tant que la
+   version de serveur sous-jacente et que les informations de métadonnées du
+   catalogue restent exactement les même.  Deux serveurs en réplication à base
+   de rejeu de journaux de transactions physique devraient avoir des valeurs de
+   <structfield>queryid</structfield> identiques pour une même requête.
+   Toutefois, les mécanismes de réplication logique ne garantissent pas de
+   conserver des réplicats identiques pour tous les détails entrant en jeu, par
+   conséquent <structfield>queryid</structfield> ne sera pas un identifiant
+   utile pour accumuler des coûts sur un ensemble de réplicats logiques.  En cas
+   de doute, il est recommandé de tester directement.
   </para>
  </sect2>
 
@@ -319,27 +322,28 @@
      <function>pg_stat_statements(showtext boolean) returns setof record</function>
      <indexterm>
       <primary>pg_stat_statements</primary>
-      <secondary>function</secondary>
+      <secondary>fonction</secondary>
      </indexterm>
     </term>
 
     <listitem>
      <para>
-      The <structname>pg_stat_statements</structname> view is defined in
-      terms of a function also named <function>pg_stat_statements</function>.
-      It is possible for clients to call
-      the <function>pg_stat_statements</function> function directly, and by
-      specifying <literal>showtext := false</literal> have query text be
-      omitted (that is, the <literal>OUT</literal> argument that corresponds
-      to the view's <structfield>query</structfield> column will return nulls).  This
-      feature is intended to support external tools that might wish to avoid
-      the overhead of repeatedly retrieving query texts of indeterminate
-      length.  Such tools can instead cache the first query text observed
-      for each entry themselves, since that is
-      all <filename>pg_stat_statements</filename> itself does, and then retrieve
-      query texts only as needed.  Since the server stores query texts in a
-      file, this approach may reduce physical I/O for repeated examination
-      of the <structname>pg_stat_statements</structname> data.
+      La vue <structname>pg_stat_statements</structname> est basée sur une
+      fonction également nommée <function>pg_stat_statements</function>.  Les
+      clients peuvent appeler la fonction <function>pg_stat_statements</function>
+      directement, et peuvent en spécifiant <literal>showtext := false</literal>
+      ne pas récupérer le texte de la requête (ce qui veut dire que l'argument
+      <literal>OUT</literal> qui correspond à la colonne <structfield>query</structfield>
+      de la vue retournera des NULL).  Cette fonctionnalité est prévue pour le
+      support d'outils externes qui pourraient vouloir éviter le surcoût de
+      récupérer de manière répétée les textes des requêtes de longueur
+      indeterminées.  De tels outils peuvent à la place eux-même mettre le
+      premier texte de requête récupéré pour chaque entrée, puisque c'est déjà
+      ce que fait <filename>pg_stat_statements</filename> lui-même, et ensuite
+      récupérer les textes de requêtes uniquement si nécessaire.  Puisque le
+      serveur stocke les textes de requête dans un fichier, cette approche
+      pourrait réduire les entrée/sorties physiques pour des vérifications
+      répétées des données de <structname>pg_stat_statements</structname>.
      </para>
     </listitem>
    </varlistentry>