root/traduc/branches/bv747/manuel/indices.sgml

<!-- $Header: /var/lib/cvs/pgsql-fr/sgml/indices.sgml,v 1.8.2.2 2005/07/15 06:33:40 guillaume Exp $ -->

<chapter id="indexes">
 <title id="indexes-title">Index</title>

 <indexterm zone="indexes">
  <primary>index</primary>
 </indexterm>

 <para>
  Les index sont une méthode courante pour augmenter les performances
  d'une base de données. Un index permet au serveur de bases de données de
  retrouver une ligne spécifique bien plus rapidement que sans index.
  Mais les index ajoutent aussi une surcharge au système de base de données
  dans son ensemble, si bien qu'ils doivent être utilisés avec discernement.
 </para>


 <sect1 id="index-intro">
  <title>Introduction</title>

  <para>
   Supposons que nous ayons une table comme celle-ci:
<programlisting>
CREATE TABLE test1 (
    id integer,
    content varchar
);
</programlisting>
   et que l'application utilise beaucoup de requêtes de la forme
<programlisting>
SELECT content FROM test1 WHERE id = <replaceable>constant</replaceable>;
</programlisting>
   Sans préparation supplémentaire, le système devrait lire la table
   <structname>test1</structname> en entier, ligne par ligne, pour trouver
   toutes les lignes qui correspondent. S'il y a beaucoup de lignes dans
   <structname>test1</structname>, et que seulement quelques lignes 
   correspondent à la requête (peut-être même zéro ou une seule), alors,
   clairement, la méthode n'est pas efficace.
   Mais si on a indiqué au système de maintenir un index sur la colonne
   <structfield>id</structfield>, alors il peut utiliser une manière
   beaucoup plus efficace pour trouver les lignes recherchées. Par exemple,
   il pourrait n'avoir à parcourir que quelques niveaux d'un arbre de 
   recherche.
  </para>

  <para>
   Une approche similaire est utilisée dans la plupart des livres autres
   que ceux de fiction: les termes et concepts qui sont fréquemment
   recherchés par les lecteurs sont listés par ordre alphabétique à la
   fin du livre. Le lecteur qui recherche un mot particulier peut
   facilement parcourir l'index, puis aller directement à la page 
   ou aux pages indiquée(s). De la même façon que l'auteur doit anticiper
   les sujets que les lecteurs risquent de rechercher, il est de la
   responsabilité du programmeur de prévoir quels index seraient avantageux.
  </para>

  <para>
   La commande suivante permet de créer un index sur la colonne
   <structfield>id</structfield> dont nous parlons:
<programlisting>
CREATE INDEX test1_id_index ON test1 (id);
</programlisting>
   Le nom <structname>test1_id_index</structname> peut être choisi
   librement, mais il est conseillé de choisir un nom qui rappelle le but
   de l'index.
  </para>

  <para>
   Pour supprimer l'index, utilisez la commande <command>DROP INDEX</command>.
   Les index peuvent être ajoutés et enlevés des tables à tout moment.
  </para>

  <para>
   Une fois l'index créé, aucune intervention supplémentaire n'est nécessaire:
   Le système met à jour l'index lorsque la table est modifiée, et utilise
   l'index dans les requêtes lorsqu'il pense que c'est plus efficace qu'une
   lecture complète de la table. Il faut néanmoins lancer la commande 
   <command>ANALYZE</command> régulièrement pour permettre à l'optimiseur
   de requêtes de prendre les bonnes décisions.
   Voyez <xref linkend="performance-tips"> pour comprendre quand et 
   pourquoi l'optimiseur décide d'utiliser ou de ne 
   <emphasis>pas</emphasis> utiliser un index.
  </para>

  <para>
   Les index peuvent aussi bénéficier aux commandes
   <command>UPDATE</command> et <command>DELETE</command> qui ont des
   conditions de recherche. Les index peuvent de plus être utilisés dans les
   jointures. Ainsi, un index défini sur une colonne qui fait partie d'une
   condition de jointure peut accélérer significativement les requêtes avec
   jointures.
  </para>

  <para>
   Lorsqu'un index est créé, le système doit le maintenir synchronisé avec
   la table. Cela rend plus lourdes les opérations de manipulation de 
   données. C'est pourquoi les index qui ne sont pas essentiels ou qui ne
   sont pas utilisés du tout doivent être supprimés. Notez qu'une requête ou
   une commande de manipulation de données ne peut utiliser qu'un index par 
   table au maximum.
  </para>
 </sect1>


 <sect1 id="indexes-types">
  <title>Types d'index</title>

  <para>
   <productname>PostgreSQL</productname> propose plusieurs types d'index:
   B-tree, R-tree, GiST et Hash. Chaque type d'index utilise un algorithme
   différent qui convient à un type particulier de requêtes.
   <indexterm>
    <primary>index</primary>
    <secondary>B-tree</secondary>
   </indexterm>
   <indexterm>
    <primary>B-tree</primary>
    <see>index</see>
   </indexterm>
   Par défaut, la commande <command>CREATE INDEX</command> crée un index
   de type B-tree, qui convient à la plupart des situations. Les index
   B-tree savent traiter les égalités et les recherches sur des tranches de
   valeurs sur les données qui peuvent être triées. En particulier, 
   l'optimiseur de requêtes de <productname>PostgreSQL</productname>
   essaie d'utiliser un index B-tree lorsque une colonne indexée est
   utilisée dans une comparaison qui utilise un de ces opérateurs:

   <simplelist type="inline">
    <member><literal>&lt;</literal></member>
    <member><literal>&lt;=</literal></member>
    <member><literal>=</literal></member>
    <member><literal>&gt;=</literal></member>
    <member><literal>&gt;</literal></member>
   </simplelist>
  </para>

  <para>
   L'optimiseur peut aussi utiliser un index B-tree pour des requêtes
   qui utilisent les opérateurs de recherche de motif <literal>LIKE</literal>,
<literal>ILIKE</literal>, <literal>~</literal>, et
   <literal>~*</literal>, <emphasis>si</emphasis> le motif est au début
   de la chaîne à rechercher. Par exemple: <literal>col LIKE
   'foo%'</literal> ou <literal>col ~ '^foo'</literal>, mais pas
   <literal>col LIKE '%bar'</literal>. Néanmoins, si votre serveur
   n'utilise pas la localisation C, il vous faudra créer l'index avec
   une classe d'opérateur spéciale. Voir <xref linkend="indexes-opclass">
   plus bas.
  </para>

  <para>
   <indexterm>
    <primary>index</primary>
    <secondary>R-tree</secondary>
   </indexterm>
   <indexterm>
    <primary>R-tree</primary>
    <see>index</see>
   </indexterm>
   Les index R-tree sont adaptés aux requêtes sur des données spatiales.
   Pour créer un index R-tree, utilisez une commande de la forme:
<synopsis>
CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> USING RTREE (<replaceable>column</replaceable>);
</synopsis>
   L'optimiseur de requêtes de <productname>PostgreSQL</productname>
   envisagera d'utiliser un index R-tree lorsqu'une colonne indexée fait
   partie d'une comparaison utilisant l'un de ces opérateurs:

   <simplelist type="inline">
    <member><literal>&lt;&lt;</literal></member>
    <member><literal>&amp;&lt;</literal></member>
    <member><literal>&amp;&gt;</literal></member>
    <member><literal>&gt;&gt;</literal></member>
    <member><literal>@</literal></member>
    <member><literal>~=</literal></member>
    <member><literal>&amp;&amp;</literal></member>
   </simplelist>
(Référez vous à <xref linkend="functions-geometry"> pour connaître la
   signification de ces opérateurs.)
  </para>

  <para>
   <indexterm>
    <primary>index</primary>
    <secondary>hash</secondary>
   </indexterm>
   <indexterm>
    <primary>hash</primary>
    <see>index</see>
   </indexterm>
   Les index hachés ne supportent que les simples comparaisons d'égalité.
   L'optimiseur de requêtes envisagera d'utiliser un index haché lorsqu'une
   colonne indexée fait partie d'une comparaison utilisant l'opérateur 
   <literal>=</literal>. La commande suivante est utilisée pour créer un index
   haché:
<synopsis>
CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> USING HASH (<replaceable>column</replaceable>);
</synopsis>
   <note>
    <para>
     Les tests ont montré que les index hachés de 
     <productname>PostgreSQL</productname> ne sont pas plus efficaces que les
     index B-tree, et que la taille de l'index et le temps de création d'un
     index hashé sont bien moins bons. Pour ces raisons, l'utilisation des
     index hachés est actuellement découragée.
    </para>
   </note>  
  </para>

  <para>
   La méthode d'index B-tree est une implémentation des B-trees à haute
   concurrence de Lehman-Yao. La méthode d'index R-tree implémente
   les R-tree standards en utilisant l'algorithme de découpage quadratique
   de Guttman. La méthode d'index par hachage est une implémentation de
   l'algorithme de hachage linéaire de Litwin.
   Nous ne mentionnons les algorithmes utilisés que pour indiquer que toutes
   ces méthodes d'indexation sont complètement dynamiques et n'ont pas
   besoin d'une optimisation périodique (au contraire, par exemple, des 
   méthodes de hachage statique).
  </para>
 </sect1>


 <sect1 id="indexes-multicolumn">
  <title>Les index multicolonnes</title>

  <indexterm zone="indexes-multicolumn">
   <primary>index</primary>
   <secondary>multi colonne</secondary>
  </indexterm>

  <para>
   Un index peut porter sur plus d'une colonne. Par exemple, si vous avez 
   une table de cette forme:
<programlisting>
CREATE TABLE test2 (
  majeur int,
  mineur int,
  nom varchar
);
</programlisting>
   (par exemple, si vous gardez votre répertoire 
   <filename class="directory">/dev</filename> dans une base de données...)
   et que vous faites fréquemment des requêtes comme:
<programlisting>
SELECT nom FROM test2 WHERE majeur = <replaceable>constante</replaceable> AND mineur = <replaceable>constante</replaceable>;
</programlisting>
   alors il est sans doute souhaitable de définir un index sur les colonnes
   <structfield>majeur</structfield> et
   <structfield>mineur</structfield> ensemble, par exemple avec:,
<programlisting>
CREATE INDEX test2_mm_idx ON test2 (majeur, mineur);
</programlisting>
  </para>

  <para>
   Actuellement, seuls les B-trees et les index GiST supportent les
   index multicolonnes. Jusqu'à 32 colonnes peuvent être indexées.
   Cette limite peut être modifiée à la compilation de
   <productname>PostgreSQL</productname>. Voyez le fichier 
   <filename>pg_config_manual.h</filename>.
  </para>

  <para>
L'optimiseur de requêtes peut utiliser un index multicolonnes pour les
   requêtes qui utilisent la colonnes la plus à gauche de la définition de
   l'index, plus un nombre quelconque des colonnes listées à sa droite, sans
   trou. Par exemple, un index sur <literal>(a, b, c)</literal> peut
   être utilisé dans des requêtes utilisant <literal>a</literal>, 
   <literal>b</literal>, et <literal>c</literal>, ou dans des requêtes 
   utilisant à la fois <literal>a</literal> et <literal>b</literal>,
   ou dans des requêtes n'utilisant que <literal>a</literal>, mais pas dans 
   une requête utilisant une autre combinaison. (Dans une requête utilisant 
   <literal>a</literal> et <literal>c</literal>, l'optimiseur pourrait choisir
   d'utiliser l'index pour <literal>a</literal>, en traitant 
   <literal>c</literal> comme une colonne ordinaire non indexée.)
   Bien sur, chaque colonne doit être utilisée avec les opérateurs appropriés
   pour le type d'index. Les clauses qui comprennent un autre opérateur ne
   seront pas prises en compte.
  </para>

  <para>
   Les index multicolonnes ne peuvent être utilisés que si les
   clauses des colonnes indexées sont jointes avec <literal>AND</literal>.
   Par exemple, 
<programlisting>
SELECT nom FROM test2 WHERE majeur = <replaceable>constant</replaceable> OR mineur = <replaceable>constant</replaceable>;
</programlisting>
   ne peut utiliser l'index <structname>test2_mm_idx</structname> (défini
   précédemment) sur les deux colonnes. (Il peut néanmoins l'utiliser pour
   faire une recherche sur la colonne <structfield>major</structfield>.)
  </para>

  <para>
   Les index multicolonnes doivent être utilisés avec parcimonie. La plupart
   du temps, un index sur une seule colonne est suffisant et économise du
   temps et de l'espace disque. Les index avec plus de trois colonnes sont
   rarement utiles, sauf cas très particuliers.
  </para>
 </sect1>


 <sect1 id="indexes-unique">
  <title>Index Uniques</title>

  <indexterm zone="indexes-unique">
   <primary>index</primary>
   <secondary>unique</secondary>
  </indexterm>

  <para>
   Les index peuvent aussi être utilisés pour garantir l'unicité des
   valeurs d'une colonne, ou l'unicité des valeurs combinées de plusieurs 
   colonnes.
<synopsis>
CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> (<replaceable>column</replaceable> <optional>, ...</optional>);
</synopsis>
   À ce jour, seuls les index B-trees peuvent être déclarés uniques.
  </para>

  <para>
   Lorsqu'un index est déclaré unique, des lignes différentes d'une table ne 
   pourront avoir une valeur égale. Les valeurs Nulles ne sont pas
   considérées comme égales. Un index unique multicolonnes ne rejettera que les
   cas où toutes les colonnes indexées sont égales dans deux lignes.
  </para>

  <para>
   <productname>PostgreSQL</productname> crée automatiquement un index
   unique quand une contrainte unique ou une clé primaire sont définies
   sur une table. L'index porte sur les colonnes qui composent la clé primaire
   ou la contrainte d'unicité (il s'agit d'un index multicolonnes, si c'est
   approprié). Cet index EST le mécanisme qui vérifie la contrainte.
  </para>

  <note>
   <para>
    La méthode la plus appropriée pour ajouter une contrainte à une table
    est <literal>ALTER TABLE ... ADD CONSTRAINT</literal>. L'utilisation des
    index pour vérifier les contraintes uniques doit être considérée comme
    un détail d'implémentation qui ne doit pas être utilisé directement.
    Il faut par contre savoir qu'il n'est pas nécessaire de créer manuellement
    un index sur les colonnes uniques. Cela dupliquerait l'index créé
    automatiquement.
   </para>
  </note>
 </sect1>


 <sect1 id="indexes-expressional">
  <title>Index sur des expressions</title>

  <indexterm zone="indexes-expressional">
   <primary>index</primary>
   <secondary sortas="expressions">sur des expressions</secondary>
  </indexterm>

  <para>
   Une colonne d'index ne correspond pas nécessairement exactement à une 
   colonne de la table associée, mais peut être une fonction ou une expression
   scalaire calculée à partir d'une ou plusieurs colonnes de la table.
   Cette fonctionnalité est utile pour obtenir un accès rapide aux tables
   basé sur les résultat des calculs.
  </para>

  <para>
   Par exemple, une façon classique de faire des comparaisons indépendantes
   de la casse est d'utiliser la fonction <function>lower</function>:
<programlisting>
SELECT * FROM test1 WHERE lower(col1) = 'value';
</programlisting>
   Si un index a été défini sur le résultat de <literal>lower(col1)</literal>,
   cette requête peut l'utiliser.
   Cet index est créé avec la commande:
<programlisting>
CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1));
</programlisting>
  </para>

  <para>
   Si nous avions déclaré cet index <literal>UNIQUE</literal>, il empêcherait
   la création de lignes dont la valeur de la colonne <literal>col1</literal> ne
   diffère que par la casse.
   Ainsi, les index sur les expressions peuvent être utilisés pour
   vérifier des contraintes qui ne peuvent êtres définies avec une simple
   contrainte.
  </para>

  <para>
   Un autre exemple, si vous faites souvent des requêtes comme celle-ci:
<programlisting>
SELECT * FROM people WHERE (first_name || ' ' || last_name) = 'John Smith';
</programlisting>
   alors il peut être utile de créer un index comme celui-ci:
<programlisting>
CREATE INDEX people_names ON people ((first_name || ' ' || last_name));
</programlisting>
  </para>

  <para>
   La syntaxe de la commande <command>CREATE INDEX</command> nécessite normalement
   de mettre des parenthèses autour de l'expression indexés, comme dans
   l'exemple précédent. Les parenthèses peuvent être omises quand l'expression
   est juste un appel de fonction, comme dans le premier exemple.
  </para>

  <para>
   Les expressions d'index sont relativement coûteuses à calculer, car
   l'expression doit être recalculée à chaque insertion ou mise à jour de
   chaque ligne. C'est pourquoi les index basés sur des expressions ne
   doivent être utilisés que quand les requêtes qui les exécutent sont très
   fréquentes.
  </para>
 </sect1>


 <sect1 id="indexes-opclass">
  <title>Classes d'Opérateurs</title>

  <indexterm zone="indexes-opclass">
   <primary>classe d'opérateurs</primary>
  </indexterm>

  <para>
   Une définition d'index peut indiquer une <firstterm>classe 
   d'opérateurs</firstterm> pour chaque colonne de l'index.
<synopsis>
CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> (<replaceable>column</replaceable> <replaceable>opclass</replaceable> <optional>, ...</optional>);
</synopsis>
   La classe d'opérateurs identifie les opérateurs que l'index doit utiliser 
   sur cette colonne. Par exemple, un index B-tree sur une colonne de type
   <type>int4</type> utiliserait la classe <literal>int4_ops</literal>;
   Cette classe d'opérateurs comprend des fonctions de comparaison pour les
   valeurs de type <type>int4</type>.
   En pratique, la classe d'opérateurs par défaut pour le type de données de la
   colonne est généralement suffisant. Les classes d'opérateurs sont utiles pour
   certains types de données, pour lesquels il pourrait y avoir plus d'un
   comportement utile de l'index.
   Par exemple, nous pourrions vouloir trier une donnée de type nombre complexe
   soit par sa valeur absolue, soit par sa partie entière.
   Nous pourrions le faire en définissant deux classes d'opérateurs pour ce 
   type de données et en sélectionnant la bonne classe en créant l'index.
  </para>

  <para>
   Il y a quelques classes d'opérateurs en plus des classes par défaut:

   <itemizedlist>
    <listitem>
     <para>
      Les classes d'opérateurs <literal>text_pattern_ops</literal>,
      <literal>varchar_pattern_ops</literal>,
      <literal>bpchar_pattern_ops</literal>, et
      <literal>name_pattern_ops</literal> supportent les index B-tree sur
      les types <type>text</type>, <type>varchar</type>,
<type>char</type>, et <type>name</type>, respectivement.
      La différence avec les classes d'opérateurs ordinaires est que
      les valeurs sont comparées strictement caractère par caractère plutôt 
      que suivant les règles de tri spécifiques à la localisation.
      Cela rend ces index utilisables pour des requêtes qui utilisent des
      recherches sur des motifs (<literal>LIKE</literal> ou des expressions 
      régulières POSIX) si le serveur n'utilise pas la localisation standard
      <quote>C</quote>.
      Par exemple, on pourrait indexer une colonne <type>varchar</type>
      comme ceci:
<programlisting>
CREATE INDEX test_index ON test_table (col varchar_pattern_ops);
</programlisting>
      Si vous utilisez la localisation C, vous pouvez à la place créer
      un index avec la classe d'opérateurs par défaut, qui sera utilisable
      pour les recherches de motifs.
      Notez aussi qu'il faut créer un index avec la classe d'opérateurs par
      défaut si vous voulez que les requêtes qui utilisent une comparaison
      ordinaire utilisent un index. De telles requêtes ne peuvent pas utiliser
      les classes d'opérateurs 
      <literal><replaceable>xxx</replaceable>_pattern_ops</literal>.
      Il est possible de créer plusieurs index sur la même colonne
      avec différentes classes d'opérateurs.
     </para>
    </listitem>
   </itemizedlist>
  </para>

  <para>
    Les requêtes suivantes montrent toutes les classes d'opérateurs prédéfinies:

<programlisting>
SELECT am.amname AS index_method,
       opc.opcname AS opclass_name
    FROM pg_am am, pg_opclass opc
    WHERE opc.opcamid = am.oid
    ORDER BY index_method, opclass_name;
</programlisting>

    Elle peut être étendue pour montrer tous les opérateurs inclus dans chaque classe:
    
<programlisting>
SELECT am.amname AS index_method,
       opc.opcname AS opclass_name,
       opr.oprname AS opclass_operator
    FROM pg_am am, pg_opclass opc, pg_amop amop, pg_operator opr
    WHERE opc.opcamid = am.oid AND
          amop.amopclaid = opc.oid AND
          amop.amopopr = opr.oid
    ORDER BY index_method, opclass_name, opclass_operator;
</programlisting>
  </para>
 </sect1>


 <sect1 id="indexes-partial">
  <title>Index partiels</title>

  <indexterm zone="indexes-partial">
   <primary>index</primary>
   <secondary>partiel</secondary>
  </indexterm>

  <para>
   Un <firstterm>index partiel</firstterm> est un index construit sur un
   sous-ensemble d'une table; le sous-ensemble est défini par une expression
   conditionnelle (appelée le <firstterm>prédicat</firstterm> de l'index
   partiel). L'index ne contient des entrées que pour les lignes de la
   table qui satisfont au prédicat.
  </para>

  <para>
   L'usage principal des index partiels est d'éviter d'indexer les valeurs
   trop courantes. Comme une requête qui fait des recherches sur une valeur 
   trop courante (qui correspond à plus de quelques pour-cent des lignes)
   n'utilisera pas cet index de toute façon, il ne sert à rien de garder 
   ces lignes dans l'index.
   Cela réduit la taille de l'index, ce qui accélère les requêtes qui 
   l'utilisent.
   Cela accélère aussi beaucoup d'opérations de mise à jour de la table car
   l'index n'a pas besoin d'être mis à jour à chaque fois.
   <xref linkend="indexes-partial-ex1"> montre une application possible de
   cette idée.
  </para>

  <example id="indexes-partial-ex1">
   <title>Mettre en place un index partiel pour exclure les valeurs courantes</title>

   <para>
    Supposons que vous enregistrez un journal d'accès à un serveur web dans une 
    base de données.
    La plupart des accès proviennent de classes d'adresses IP internes à votre
    organisation, mais certaines viennent d'ailleurs (disons des employés connectés 
    par modem).
    Si vos recherches sur des adresses IP concernent essentiellement les accès 
    extérieures, vous n'avez probablement pas besoin d'indexer les classes 
    d'adresses IP qui correspondent au sous-réseau de votre organisation.

   </para>

   <para>
    Supposons que la table soit comme ceci:
<programlisting>
CREATE TABLE access_log (
    url varchar,
    client_ip inet,
    ...
);
</programlisting>
   </para>

   <para>
    Pour créer un index partiel qui corresponde à notre exemple, il faut utiliser 
    une commande comme celle-ci:
<programlisting>
CREATE INDEX access_log_client_ip_ix ON access_log (client_ip)
    WHERE NOT (client_ip > inet '192.168.100.0' AND client_ip < inet '192.168.100.255');
</programlisting>
   </para>

   <para>
    Une requête typique qui peut utiliser cet index est:
<programlisting>
SELECT * FROM access_log WHERE url = '/index.html' AND client_ip = inet '212.78.10.32';
</programlisting>
    Une requête qui ne peut pas l'utiliser est:
<programlisting>
SELECT * FROM access_log WHERE client_ip = inet '192.168.100.23';
</programlisting>
   </para>

   <para>
    Observez que cet type d'index partiel nécessite que les valeurs courantes
    soient prédéterminées. Si la distribution des valeurs est inhérente
    (du fait de la nature de l'application) et statique (ne changeant pas dans 
    le temps), ce n'est pas trop difficile, mais si les valeurs courantes sont
    simplement dues au hasard, cela peut demander beaucoup de travail de maintenance.
   </para>
  </example>

  <para>
   Il est aussi possible d'exclure des valeurs de l'index qui ne correspondent
   pas aux requêtes courantes; ceci est montré dans <xref
   linkend="indexes-partial-ex2">. Cette méthode donne les mêmes avantages que
la précédente, mais empêche les valeurs <quote>sans intérêt</quote>
   d'être accédées. Évidemment, mettre en place des index partiels pour
   ce genre de scénario nécessite beaucoup de soin et d'expérimentation.
  </para>

  <example id="indexes-partial-ex2">
   <title>Mettre en place un index partiel pour exclure les valeurs inintéressantes</title>

   <para>
    Si vous avez une table qui contient des commandes facturées et des
    commandes non facturées, que les commandes non facturées ne prennent
    qu'une petite fraction de l'espace dans la table, et que ces commandes
    non facturées sont les plus accédées, alors vous pouvez améliorer les 
    performances en créant un index limité aux lignes non facturées.
    La commande pour créer l'index ressemblerait à ceci:
<programlisting>
CREATE INDEX orders_unbilled_index ON orders (order_nr)
    WHERE billed is not true;
</programlisting>
   </para>

   <para>
    La requête suivante utilisera probablement cet index:
<programlisting>
SELECT * FROM orders WHERE billed is not true AND order_nr < 10000;
</programlisting>
    Néanmoins, l'index peut aussi être utilisé dans des requêtes qui
    n'utilisent pas <structfield>order_nr</structfield>, comme:
<programlisting>
SELECT * FROM orders WHERE billed is not true AND amount > 5000.00;
</programlisting>
    Ceci n'est pas aussi efficace qu'un index partiel sur la colonne
    <structfield>amount</structfield>, car le système doit lire l'index en entier.
    Néanmoins, s'il y a assez peu de commandes non facturées, l'utilisation
    de cet index partiel pour trouver les commandes non facturées peut être
    efficace.
   </para>

   <para>
    Notez que cette requête ne peut pas utiliser cet index:
<programlisting>
SELECT * FROM orders WHERE order_nr = 3501;
</programlisting>
    La commande 3501 peut faire partie des commandes facturées ou
    bien des commandes non facturées.
   </para>
  </example>

  <para>
   <xref linkend="indexes-partial-ex2"> illustre aussi le fait que la colonne
   indexée et la colonne utilisée dans le prédicat ne sont pas nécessairement
   les mêmes. <productname>PostgreSQL</productname> supporte tous les
   prédicats sur les index partiels, tant que ceux-ci ne portent que sur des
   champs de la table indexée. Néanmoins, il faut se rappeler le prédicat doit
   correspondre aux conditions utilisées dans les requêtes qui sont supposées
   profiter de l'index. Pour être précis, un index partiel ne peut être utilisé
   pour une requête que si le système peut reconnaître que la clause 
   <literal>WHERE</literal> de la requête implique mathématiquement le prédicat de
   l'index.
   <productname>PostgreSQL</productname> n'a pas de méthode sophistiquée de
   démonstration de théorème pour reconnaître que des expressions apparemment
   différentes sont mathématiquement équivalentes. (Non seulement une telle 
   méthode générale de démonstration serait extrêmement complexe à créer,
   mais en plus elle serait probablement trop lente pour être d'une quelconque
   utilité.)
   Le système peut reconnaître des implications d'inégalités simples, par 
   exemple <quote>x &lt; 1</quote> implique <quote>x &lt; 2</quote>; sinon,
   la condition du prédicat doit correspondre exactement à une partie de la
   clause <literal>WHERE</literal> de la requête, sans quoi l'index ne sera pas
   considéré comme utilisable.
  </para>

  <para>
   Le troisième usage possible des index partiels ne nécessite pas que
   l'index soit utilisé dans des requêtes. L'idée ici est de créer un index
   unique sur un sous-ensemble de la table, comme dans <xref
   linkend="indexes-partial-ex3">. Ceci permet de mettre en place une unicité
   parmi le sous-ensemble des lignes de la table qui satisfont au prédicat,
   sans contraindre les lignes qui n'y satisfont pas.
  </para>

  <example id="indexes-partial-ex3">
   <title>Mettre en place un index unique partiel</title>

   <para>
    Supposons que nous ayons une table qui décrive des résultats de tests.
    Nous voulons nous assurer qu'il n'y a qu'une seule entrée 
    <quote>succès</quote> (success) pour chaque combinaison de sujet (subject) et de
    résultat (target), mais il peut y avoir un nombre quelconque d'entrées
    <quote>echec</quote>. Voici une façon de le faire.
<programlisting>
CREATE TABLE tests (
    subject text,
    target text,
    success boolean,
    ...
);

CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target)
    WHERE success;
</programlisting>
    C'est une méthode très efficace pour le faire quand il y a peu de tests
    réussis et beaucoup de tests en échec.
   </para>
  </example>

  <para>
   Enfin, un index partiel peut aussi être utilisé pour passer outre aux
   choix de plan d'exécution de requête du système.
   Il peut arriver avec certains jeux de données particuliers que le
   système utilise un index alors qu'il ne devrait vraiment pas le faire.
   Dans ce cas, on peut mettre en place l'index de telle faon qu'il ne soit 
   pas utilisé pour la requête qui pose problème.
   Normalement, <productname>PostgreSQL</productname> fait des choix d'usage d'index
   raisonnables. Par exemple, il les évite pour rechercher les valeurs communes,
   si bien que l'exemple précédent n'économise que la taille de l'index, il
   n'est en fait pas nécessaire pour éviter l'usage de l'index.
   En fait, les choix de plan d'exécution grossièrement incorrects doivent
   être traités comme des bogues, et être transmis à l'équipe de développement.
  </para>

  <para>
   Gardez à l'esprit que mettre en place un index partiel indique que vous
   connaissez vos données au moins aussi bien que l'analyseur de requêtes,
   et en particulier que vous savez quand un index peut être profitable.
   Une telle connaissance nécessite de l'expérience et une bonne
   compréhension du fonctionnement des index de <productname>PostgreSQL</productname>.
   Dans la plupart des cas, les index partiels ne représentent pas un
   gros gain par rapport aux index classiques.
  </para>

  <para>
   Vous trouverez plus d'informations sur les index partiels
   en lisant <xref linkend="STON89b">, <xref linkend="OLSON93">, 
et <xref linkend="SESHADRI95">.
  </para>
 </sect1>

 <sect1 id="indexes-examine">
  <title>Examiner l'usage des index</title>

  <indexterm zone="indexes-examine">
   <primary>index</primary>
   <secondary>examiner l'usage</secondary>
  </indexterm>

  <para>
   Bien que les index de <productname>PostgreSQL</productname> n'aient pas besoin
   de maintenance ni d'optimisation, il est important de s'assurer que les
   index sont effectivement utilisés sur un système en production.
   On vérifie l'utilisation d'un index pour une requête particulière avec
   la commande <xref linkend="sql-explain" endterm="sql-explain-title">.
   Son utilisation dans notre cas est expliquée dans 
   <xref linkend="using-explain">.
   Il est aussi possible de rassembler des statistiques globales
   sur l'utilisation des index sur un serveur en cours de fonctionnement,
   comme décrit dans <xref linkend="monitoring-stats">.
  </para>

  <para>
   Il est difficile de donner une procédure générale pour déterminer
   quels index doivent être créés. Plusieurs cas typiques ont été
   cités dans les exemples précédents.
   Une bonne dose d'expérimentation sera nécessaire dans de nombreux cas.
   Le reste de cette section donne quelques pistes.
  </para>

  <itemizedlist>
   <listitem>
    <para>
     La première chose à faire est de lancer 
     <xref linkend="sql-analyze" endterm="sql-analyze-title">.
     Cette commande collecte les informations sur la distribution des
     valeurs dans la table. Cette information est nécessaire pour essayer de
     deviner le nombre lignes retournées par une requête. L'optimiseur
     de requêtes en a besoin pour donner des coûts réalistes aux différents
     plans de requêtes possibles. En l'absence de statistiques réelles,
     le système utilise quelques valeurs par défaut, qui ont toutes les chances
     d'être inadaptées. Examiner l'utilisation des index par une application
     sans avoir lancé <command>ANALYZE</command> préalablement est du coup
     une cause perdue.
    </para>
   </listitem>

   <listitem>
    <para>
     Utilisez des données réelles pour l'expérimentation. Utiliser des
     données de test pour mettre en place des index vous permettra
     de trouver les index dont vous avez besoin pour vos données de test,
     mais c'est tout.
    </para>

    <para>
     Il est particulièrement néfaste d'utiliser un jeu de données 
     constitué en réduisant proportionnellement des données réelles.
     Alors qu'une requête sélectionnant 1000 lignes parmi 100000 pourrait
     utiliser un index, il est peu probable qu'une requête sélectionnant 1 ligne
     dans une table de 100 lignes le fasse, parce que les 100 lignes
     tiennent probablement dans une seule page sur le disque, et qu'il n'y a
     aucun plan d'exécution qui puisse aller plus vite que la lecture 
     d'une seule page.
    </para>

    <para>
     Soyez aussi vigilant en créant des données de test, ce qui est souvent
     inévitable quand l'application n'est pas encore en production.
     Les valeurs qui sont très similaires, complètement aléatoire, ou
     insérées déjà triées peuvent modifier la distribution des données et
     fausser les statistiques.
    </para>
   </listitem>

   <listitem>
    <para>
     Quand les index ne sont pas utilisés, il peut être utile pour
     les tests de forcer leur utilisation. Certains paramètres d'exécution
     du serveur peuvent interdire certains types de plans (décrits dans 
     <xref linkend="runtime-config">).
     Par exemple, en interdisant les lectures séquentielles de tables 
     <varname>enable_seqscan</varname>) et les jointures à boucles imbriquées
     (<varname>enable_nestloop</varname>), qui sont les deux plans les plus
     basiques, on forcera le système à utiliser un plan différent.
     Si le système continue néanmoins à choisir une lecture séquentielle
     ou une jointure à boucles imbriquées, alors il y a probablement
     un problème plus fondamental qui empêche l'utilisation de l'index,
     par exemple que la condition ne correspond pas à l'index.
     (Les sections précédentes expliquent quelles sortes de requêtes peuvent
     utiliser quelles sortes d'index.)
    </para>
   </listitem>

   <listitem>
    <para>
     Si l'index est effectivement utilisé en forçant son utilisation,
     alors il y a deux possibilités: Soit le système a raison et 
     l'utilisation de l'index est effectivement inappropriée, soit les
     coûts estimés des plans de requêtes ne reflètent pas la réalité.
     Il faut alors comparer la durée de la requête avec et sans
     index. La commande <command>EXPLAIN ANALYZE</command> peut être
     utile pour cela.
    </para>
   </listitem>

   <listitem>
    <para>
     S'il apparaît que les estimations de coûts sont fausses, il y a
     de nouveau deux possibilités. Le coût total est calculé à partir du
     coût par ligne de chaque n&oelig;ud du plan, multiplié par l'estimation de
     sélectivité du n&oelig;ud de plan.
     Le coût des n&oelig;uds de plan peut être optimisé avec
     des paramètres d'exécution (décrits dans <xref linkend="runtime-config">).
     Une estimation de sélectivité inadaptée est due à des statistiques 
     insuffisantes. Il est peut être possible de les améliorer en 
     optimisant les paramètres de collecte de statistiques.
     Voir <xref linkend="sql-altertable" endterm="sql-altertable-title">).
    </para>

    <para>
     Si vous n'arrivez pas à ajuster les coûts pour qu'ils représentent
     mieux la réalité, alors vous devrez forcer l'utilisation de l'index
     explicitement.
     Vous pouvez aussi, si vous le voulez, contacter les développeurs de
     <productname>PostgreSQL</productname> afin qu'ils examinent le problème.
    </para>
   </listitem>
  </itemizedlist>
 </sect1>
</chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"./reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/lib/sgml/catalog")
sgml-local-ecat-files:nil
End:
-->