Nouvelles traductions

postgresql/bloom.xml

@@ -9,34 +9,36 @@
  </indexterm>
 
  <para>
-  <literal>bloom</literal> provides an index access method based on
-  <ulink url="http://en.wikipedia.org/wiki/Bloom_filter">Bloom filters</ulink>.
+  <literal>bloom</literal> fournit une méthode d'accès aux index basée sur les
+  <ulink url="http://en.wikipedia.org/wiki/Bloom_filter">filtres Bloom</ulink>.
  </para>
 
  <para>
-  A Bloom filter is a space-efficient data structure that is used to test
-  whether an element is a member of a set.  In the case of an index access
-  method, it allows fast exclusion of non-matching tuples via signatures
-  whose size is determined at index creation.
+  Un filtre Bloom est une structure de données efficace en terme d'espace
+  disque, utilisée pour tester si un élément fait partie d'un ensemble. Dans
+  le cas d'une méthode d'accès aux index, il permet une exclusion rapide des
+  lignes ne correspondant pas à la recherche via des signatures dont la taille
+  est déterminée lors de la création de l'index.
  </para>
 
  <para>
-  A signature is a lossy representation of the indexed attribute(s), and as
-  such is prone to reporting false positives; that is, it may be reported
-  that an element is in the set, when it is not.  So index search results
-  must always be rechecked using the actual attribute values from the heap
-  entry.  Larger signatures reduce the odds of a false positive and thus
-  reduce the number of useless heap visits, but of course also make the index
-  larger and hence slower to scan.
+  Une signature est une représentation à perte des colonnes indexées et, de ce
+  fait, est sujet à renvoyer des faux positifs&nbsp;; c'est-à-dire qu'il peut
+  indiquer qu'un élément fait partie d'un ensemble alors que ce n'est pas
+  vrai. De ce fait, les résultats d'une recherche doivent toujours être
+  vérifiés en utilisant les valeurs réelles des colonnes à partir de la ligne
+  dans la table. Les signatures plus larges réduisent le risque de faux
+  positif et, de ce fait, réduisent le nombre de visites inutiles à la table.
+  Cependant, l'index est plus volumineux et de ce fait plus lent à parcourir.
  </para>
 
  <para>
-  This type of index is most useful when a table has many attributes and
-  queries test arbitrary combinations of them.  A traditional btree index is
-  faster than a bloom index, but it can require many btree indexes to support
-  all possible queries where one needs only a single bloom index.  Note
-  however that bloom indexes only support equality queries, whereas btree
-  indexes can also perform inequality and range searches.
+  Ce type d'index est principalement utile quand une table a de nombreuses
+  colonnes et que les requêtes testent des combinaisons arbitraires de ces
+  colonnes. Un index btree traditionnel est plus rapide qu'un index bloom mais
+  il en faut généralement plusieurs pour supporter toutes les requêtes que
+  gèrerait un seul index bloom. Il est à noter que les index peuvent aussi
+  réaliser des recherches d'inégalité et d'intervalles.
  </para>
 
  <sect2>
@@ -52,8 +54,9 @@
     <term><literal>length</literal></term>
     <listitem>
      <para>
-      Length of each signature (index entry) in bits. The default
-      is <literal>80</literal> bits and maximum is <literal>4096</literal>.
+      Longueur de chaque signature (enregistrement dans l'index) en bits. La
+      valeur par défaut est de  <literal>80</literal> et le maximum est
+      <literal>4096</literal>.
      </para>
     </listitem>
    </varlistentry>
@@ -63,10 +66,11 @@
     <term><literal>col1 &mdash; col32</literal></term>
     <listitem>
      <para>
-      Number of bits generated for each index column. Each parameter's name
-      refers to the number of the index column that it controls.  The default
-      is <literal>2</literal> bits and maximum is <literal>4095</literal>.  Parameters for
-      index columns not actually used are ignored.
+      Nombre de bits générés pour chaque colonne d'index. Le nom de chaque
+      paramètre fait référence au numéro de la colonne d'index qu'il contrôle.
+      La valeur par défaut est de <literal>2</literal> et le maximum est de
+      <literal>4095</literal>. Les paramètres pour les colonnes d'index qui ne
+      sont pas encore utilisés sont ignorés.
      </para>
     </listitem>
    </varlistentry>
@@ -77,7 +81,7 @@
   <title>Exemples</title>
 
   <para>
-   This is an example of creating a bloom index:
+   Voici un exemple de création d'un index bloom&nbsp;:
   </para>
 
 <programlisting>
@@ -86,16 +90,18 @@ CREATE INDEX bloomidx ON tbloom USING bloom (i1,i2,i3)
 </programlisting>
 
   <para>
-   The index is created with a signature length of 80 bits, with attributes
-   i1 and i2 mapped to 2 bits, and attribute i3 mapped to 4 bits.  We could
-   have omitted the <literal>length</literal>, <literal>col1</literal>,
-   and <literal>col2</literal> specifications since those have the default values.
+   L'index est créé avec une longueur de signature de 80 bits, avec les
+   colonnes i1 et i2 correspondant à 2 bits, et la colonne i3 correspondant à
+   4 bits. Nous pourrions avoir omis les informations
+   <literal>length</literal>, <literal>col1</literal>, et
+   <literal>col2</literal> étant données qu'elles ont la valeur par défaut.
   </para>
 
   <para>
-   Here is a more complete example of bloom index definition and usage, as
-   well as a comparison with equivalent btree indexes.  The bloom index is
-   considerably smaller than the btree index, and can perform better.
+   Voici un exemple plus complet de définition et d'utilisation d'un index
+   bloom, ainsi qu'une comparaison avec les index btree équivalents. L'index
+   bloom est fortement plus petit que l'index btree et propose de meilleures
+   performances.
   </para>
 
 <programlisting>
@@ -127,7 +133,8 @@ CREATE INDEX
 </programlisting>
 
   <para>
-   A sequential scan over this large table takes a long time:
+   Un parcours séquentiel prend beaucoup de temps sur cette table
+   volumineuse&nbsp;:
 <programlisting>
 =# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
                                                  QUERY PLAN
@@ -142,8 +149,8 @@ CREATE INDEX
   </para>
 
   <para>
-   So the planner will usually select an index scan if possible.
-   With a btree index, we get results like this:
+   Donc l'optimiser sélectionnera habituellement un parcours d'index si
+   possible. Avec un index btree, nous obtenons ce résultat&nbsp;:
 <programlisting>
 =# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
                                                            QUERY PLAN
@@ -158,7 +165,7 @@ CREATE INDEX
   </para>
 
   <para>
-   Bloom is better than btree in handling this type of search:
+   Bloom est meilleur que btree pour la gestion de ce type de recherche&nbsp;:
 <programlisting>
 =# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
                                                         QUERY PLAN
@@ -173,19 +180,21 @@ CREATE INDEX
  Execution time: 76.778 ms
 (8 rows)
  </programlisting>
-   Note the relatively large number of false positives: 2439 rows were
-   selected to be visited in the heap, but none actually matched the
-   query.  We could reduce that by specifying a larger signature length.
-   In this example, creating the index with <literal>length=200</literal>
-   reduced the number of false positives to 55; but it doubled the index size
-   (to 306 MB) and ended up being slower for this query (125 ms overall).
+   Notez le nombre relativement important de faux positifs&nbsp;: 2349 lignes
+   ont été sélectionnées pour être vérifiées dans la table, amaus aucune n'a
+   réellement correspondu au filtre de la requête. Nous pouvons réduire ça en
+   précisant une longueur de signature plus importante. Dans cet exemple,
+   créer l'index avec <literal>length=200</literal> a réduit le nombre de faux
+   positifs à 55. Par contre, il a doublé la taille de l'index (306 Mo) et
+   s'est révélé plus lent pour cette requête (125 ms globalement).
   </para>
 
   <para>
-   Now, the main problem with the btree search is that btree is inefficient
-   when the search conditions do not constrain the leading index column(s).
-   A better strategy for btree is to create a separate index on each column.
-   Then the planner will choose something like this:
+   Maintenant, le problème principal avec la recherche btree est que btree
+   n'est pas efficace quand les conditions de recherche ne contraignent pas
+   les premières colonnes de l'index. Une meilleure stratégie pour le btree
+   est de créer un index séparé pour chaque colonne. À ce moment-là,
+   l'optimiseur pourra choisir quelque chose comme&nbsp;:
 <programlisting>
 =# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
                                                           QUERY PLAN
@@ -201,20 +210,21 @@ CREATE INDEX
  Execution time: 0.280 ms
 (9 rows)
  </programlisting>
-   Although this query runs much faster than with either of the single
-   indexes, we pay a large penalty in index size.  Each of the single-column
-   btree indexes occupies 214 MB, so the total space needed is over 1.2GB,
-   more than 8 times the space used by the bloom index.
+   Bien que cette requête s'exécute plus rapidement qu'avec des index seuls,
+   nous payons une large pénalité à cause de la taille de l'index. Chacun des
+   index btree simple colonne occupe 214 Mo, soit un espace total de plus de
+   1,2 Go, autrement dit huit fois la place utilisée par l'index bloom.
   </para>
  </sect2>
 
  <sect2>
-  <title>Operator Class Interface</title>
+  <title>Interface de la classe d'opérateur</title>
 
   <para>
-   An operator class for bloom indexes requires only a hash function for the
-   indexed datatype and an equality operator for searching. This example
-   shows the opclass definition for the <type>text</type> data type:
+   Une classe d'opérateur pour les index bloom requiert une fonction de
+   hachage pour le type de données indexé et un opérateur d'égalité pour la
+   recherche. Cet exemple montre la définition de la classe d'opérateur pour
+   le type de données <type>text</type>&nbsp;:
   </para>
 
 <programlisting>
@@ -232,16 +242,16 @@ DEFAULT FOR TYPE text USING bloom AS
    <itemizedlist>
     <listitem>
      <para>
-      Only operator classes for <type>int4</type> and <type>text</type> are
-      included with the module.
+      Seules les classes d'opérateur pour <type>int4</type> et
+      <type>text</type> sont inclus avec le module.
      </para>
     </listitem>
 
     <listitem>
      <para>
-      Only the <literal>=</literal> operator is supported for search.  But
-      it is possible to add support for arrays with union and intersection
-      operations in the future.
+      Seul l'opérateur <literal>=</literal> est supporté pour la recherche. Mais il est
+      possible d'ajouter le support des tableaux avec les opérations union et intersection
+      dans le futur.
      </para>
     </listitem>
    </itemizedlist>
@@ -253,17 +263,17 @@ DEFAULT FOR TYPE text USING bloom AS
 
   <para>
    Teodor Sigaev <email>teodor@postgrespro.ru</email>,
-   Postgres Professional, Moscow, Russia
+   Postgres Professional, Moscou, Russie
   </para>
 
   <para>
    Alexander Korotkov <email>a.korotkov@postgrespro.ru</email>,
-   Postgres Professional, Moscow, Russia
+   Postgres Professional, Moscou, Russie
   </para>
 
   <para>
    Oleg Bartunov <email>obartunov@postgrespro.ru</email>,
-   Postgres Professional, Moscow, Russia
+   Postgres Professional, Moscou, Russie
   </para>
  </sect2>