Update indexam.xml

relecture sur v 9.6.1

postgresql/indexam.xml

@@ -8,47 +8,45 @@
  <title>Définition de l'interface des méthodes d'accès aux index</title>
 
  <para>
-  Ce chapitre définit l'interface entre le système
+  Ce chapitre définit l'interface entre le cœur du système de
   <productname>PostgreSQL</productname> et les <firstterm>méthodes d'accès
-   aux index</firstterm>, qui gérent les types d'index individuels. Le système principal
+   aux index</firstterm>, qui gérent chaque type d'index. Le système principal
   ne sait rien des index en dehors de ce qui est spécifié ici. Il est donc
-  possible de développer de nouveaux types d'index en écrivant du code
+  possible de développer des types d'index entièrement nouveaux en écrivant du code
   supplémentaire.
  </para>
 
  <para>
-  Tous les index de <productname>PostgreSQL</productname> sont connus
-  techniquement en tant qu'<firstterm>index secondaires</firstterm>&nbsp;; c'est-à-dire
-  que l'index est séparé physiquement du fichier de table qu'il décrit. Chaque index
-  est stocké dans sa propre <firstterm>relation</firstterm> physique et donc décrit
+  Tous les index de <productname>PostgreSQL</productname> sont 
+  techniquement des <firstterm>index secondaires</firstterm>&nbsp;; c'est-à-dire
+  que l'index est séparé physiquement du fichier de la table qu'il décrit. Chaque index
+  est stocké dans sa propre <firstterm>relation</firstterm> physique et est donc décrit
   par une entrée dans le catalogue <structname>pg_class</structname>. Le contenu d'un
   index est entièrement contrôlé par la méthode d'accès à l'index. En
   pratique, toutes les méthodes d'accès aux index les divisent en pages de
   taille standard de façon à utiliser le gestionnaire de stockage
-  et le gestionnaire de tampon pour accéder au contenu de l'index. De plus,
+  et le gestionnaire de tampon pour accéder au contenu de l'index. (De plus,
   toutes les méthodes existantes d'accès aux index utilisent la disposition
   de page standard décrite dans <xref linkend="storage-page-layout"/> et la plupart
   ont le même format pour les en-têtes de ligne de
-  l'index&nbsp;; mais ces décisions ne sont pas contraintes sur une méthode
-  d'index.
+  l'index&nbsp;; mais ce ne sont pas des obligations pour toutes les méthodes d'accès.)
  </para>
 
  <para>
-  Dans les faits, un index est une correspondance entre les valeurs des clés
-  de données et les
-  identifiants de lignes (<firstterm>tuple identifiers</firstterm>, ou <acronym>TIDs</acronym>)
-  des versions de lignes dans la table parent de l'index. Un TID consiste en un
-  numéro de bloc et un numéro d'élément à l'intérieur de ce bloc (voir <xref
-  linkend="storage-page-layout"/>). C'est une information suffisante pour
-  récupérer une version de ligne particulière à partir de la table. Les index
-  n'ont pas directement la connaissance de l'existence éventuelle, sous MVCC,
+  Dans les faits, un index est une correspondance entre certaines valeurs de données clés
+  et les  identifiants des lignes (<firstterm>tuple identifiers</firstterm>, ou <acronym>TIDs</acronym>),
+  dans leurs différentes versions,  dans la table parent de l'index. Un TID consiste en un
+  numéro de bloc et un numéro d'élément dans ce bloc (voir <xref
+  linkend="storage-page-layout"/>). L'information est suffisante pour
+  récupérer une version d'une ligne particulière à partir de la table. Les index
+  n'ont pas directement la connaissance de l'existence éventuelle, à cause du MVCC,
   de plusieurs versions de la même ligne logique&nbsp;; pour un index, chaque ligne
-  est un objet indépendant qui a besoin de sa propre entrée dans l'index. Du
-  coup, la mise à jour d'une ligne crée toujours toutes les nouvelles entrées
-  d'index pour la ligne, même si les valeurs de la clé ne changent pas.
-  (Les lignes HOT sont une exception&nbsp;; mais les index ne sont pas
-  concernés.) Les entrées d'index pour les lignes mortes sont réclamées (par
-  le VACUUM) lorsque les lignes mortes elles-même sont réclamées.
+  est un objet indépendant qui a besoin de sa propre entrée. En conséquence, 
+  la mise à jour d'une ligne crée toujours de nouvelles entrées
+  dans l'index pour cette ligne, même si les valeurs de la clé ne changent pas.
+  (Les lignes HOT sont une exception&nbsp;; mais les index ne s'en occupent pas).
+  Les entrées d'index pour les lignes mortes sont nettoyées (par
+  le VACUUM) lorsque les lignes mortes elles-même sont nettoyées.
  </para>
 
  <sect1 id="index-api">