Changeset 1156

Show
Ignore:
Timestamp:
09/29/08 18:55:23 (2 months ago)
Author:
sas
Message:

Hi han

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/postgresql/indexam.xml

    r973 r1156  
    1111   Ce chapitre définit l'interface entre le système 
    1212   <productname>PostgreSQL</productname> et les <firstterm>méthodes d'accès 
    13    aux index</firstterm>, qui gére les types d'index individuels. Le système principal 
    14    ne sait rien des index en dehors de ce qui est spécifié ici, donc il est 
    15    possible de développer de nouveaux types d'index en écrivant un code 
     13   aux index</firstterm>, qui gérent les types d'index individuels. Le système principal 
     14   ne sait rien des index en dehors de ce qui est spécifié ici. Il est donc 
     15   possible de développer de nouveaux types d'index en écrivant du code 
    1616   supplémentaire. 
    1717  </para> 
    …… 
    2020   Tous les index de <productname>PostgreSQL</productname> sont connus 
    2121   techniquement en tant qu'<firstterm>index secondaires</firstterm>&nbsp;; c'est-à-dire 
    22    que l'index est séparé physiquement de la table qu'il décrit. Chaque index 
    23    est stocké dans sa propre <firstterm>relation</firstterm> physique et est donc décrit 
     22   que l'index est séparé physiquement du fichier de table qu'il décrit. Chaque index 
     23   est stocké dans sa propre <firstterm>relation</firstterm> physique et donc décrit 
    2424   par une entrée dans le catalogue <structname>pg_class</structname>. Le contenu d'un 
    25    index est entièrement sous le contrôle de la méthode d'accès à l'index. En 
    26    pratique, toutes les méthodes d'accès aux index se divisent en pages de 
    27    taille standard pour qu'elles puissent utiliser le gestionnaire de stockage 
    28    et le gestionnaire de tampon pour accéder au contenu de l'index (de plus, 
     25   index est entièrement contrôlé par la méthode d'accès à l'index. En 
     26   pratique, toutes les méthodes d'accès aux index les divisent en pages de 
     27   taille standard de façon à utiliser le gestionnaire de stockage 
     28   et le gestionnaire de tampon pour accéder au contenu de l'index. De plus, 
    2929   toutes les méthodes existantes d'accès aux index utilisent la disposition 
    30    de la page standard décrite dans <xref linkend="storage-page-layout"/>, et 
    31    elles utilisent toutes le même format pour les en-têtes de ligne de 
     30   de page standard décrite dans <xref linkend="storage-page-layout"/> et 
     31   le même format pour les en-têtes de ligne de 
    3232   l'index&nbsp;; mais ces décisions ne sont pas contraintes sur une méthode 
    33    d'index). 
    34   </para> 
    35  
    36   <para> 
    37    En fait, un index est une correspondance de valeurs clés de données en 
     33   d'index. 
     34  </para> 
     35 
     36  <para> 
     37   Dans les faits, un index est une correspondance entre les valeurs des clés 
     38   de données et les 
    3839   identifiants de lignes (<firstterm>tuple identifiers</firstterm>, ou <acronym>TIDs</acronym>) 
    3940   des versions de lignes dans la table parent de l'index. Un TID consiste en un 
    …… 
    4142   linkend="storage-page-layout"/>). C'est une information suffisante pour 
    4243   récupérer une version de ligne particulière à partir de la table. Les index 
    43    ne sont pas directement conscients que, sous MVCC, il pourrait y avoir 
    44    plusieurs versions de la même ligne logique&nbsp;; pour un index, chaque ligne 
     44   n'ont pas directement la connaissance de l'existence éventuelle, sous MVCC, 
     45   de plusieurs versions de la même ligne logique&nbsp;; pour un index, chaque ligne 
    4546   est un objet indépendant qui a besoin de sa propre entrée dans l'index. Du 
    46    coup, une mise à jour d'une ligne crée toujours toutes les nouvelles entrées 
     47   coup, la mise à jour d'une ligne crée toujours toutes les nouvelles entrées 
    4748   d'index pour la ligne, même si les valeurs de la clé ne changent pas. Les 
    4849   entrées d'index pour les lignes mortes sont réclamées (par le VACUUM) lorsque 
    …… 
    5960   constitué de références à des entrées de 
    6061   <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link> 
    61    identifiant les fonctions d'accès à l'index fournis par la méthode d'accès. 
    62    Les API pour ces fonctions sont définies plus tard dans ce chapitre. De plus, 
     62   qui identifient les fonctions d'accès à l'index fournies par la méthode d'accès. 
     63   Les API de ces fonctions sont définies plus loin dans ce chapitre. De plus, 
    6364   la ligne de <structname>pg_am</structname> spécifie quelques propriétés fixes 
    64    de la méthode d'accès, comme le support des index à plusieurs colonnes. Il 
     65   de la méthode d'accès, comme le support des index multi-colonnes. Il 
    6566   n'existe pas de support spécial pour la création ou la suppression d'entrées 
    6667   dans <structname>pg_am</structname>&nbsp;; toute personne capable d'écrire 
    67    une nouvelle méthode d'accès est supposée assez compétente pour insérer une 
    68    ligne appropriée elle-même. 
     68   une nouvelle méthode d'accès est supposée assez compétente pour insérer la 
     69   ligne appropriée. 
    6970  </para> 
    7071 
    …… 
    7778   <link linkend="catalog-pg-amop"><structname>pg_amop</structname></link> et 
    7879   <link linkend="catalog-pg-amproc"><structname>pg_amproc</structname></link>. 
    79    Ces entrées autorisent le planificateur à déterminer le type de qualification 
    80    des requêtes pouvant être utilisé avec les index de cette méthode d'accès. 
     80   Ces entrées permettent au planificateur de déterminer les types de qualification 
     81   des requêtes qui peuvent être utilisés avec les index de cette méthode d'accès. 
    8182   Les familles et classes d'opérateurs sont décrites dans <xref 
    8283   linkend="xindex"/>, qui est un élément requis pour comprendre ce chapitre. 
    …… 
    8889   le définissant comme une relation physique, et une entrée dans 
    8990   <link linkend="catalog-pg-index"><structname>pg_index</structname></link> 
    90    affichant le contenu logique de l'index &mdash; c'est-à-dire des colonnes 
    91    d'index qu'il a et de la sémantique de ces colonnes, de la façon dont elles 
    92    sont récupérées par les classes d'opérateur associées. Les colonnes de 
    93    l'index (valeurs clés) peuvent être soit des colonnes simples de la table 
    94    sous-jacente soit des expressions sur les lignes de la table. Habituellement, 
    95    la méthode d'accès à l'index n'a aucun intérêt dans l'emplacement d'où 
    96    provient les valeurs clés de l'index (ce sont toujours des valeurs clés 
    97    pré-traitées) mais il sera très intéressé dans les informations de la classe 
    98    d'opérateur dans <structname>pg_index</structname>. Ces entrées de catalogue 
    99    peuvent être accédées car elles font partie de la structure de données de 
    100    <structname>Relation</structname> qui est passée dans toutes les opérations de l'index. 
    101   </para> 
    102  
    103   <para> 
    104    Certaines des colonnes d'options de <structname>pg_am</structname> ont des 
    105    obligations peu évidentes. Les besoins de <structfield>amcanunique</structfield> 
     91   affichant le contenu logique de l'index &mdash; c'est-à-dire ses colonnes 
     92   d'index et la sémantique de ces colonnes, telles que 
     93   récupérées par les classes d'opérateur associées. Les colonnes de 
     94   l'index (valeurs clés) peuvent être des colonnes simples de la table 
     95   sous-jacente ou des expressions sur les lignes de la table. Habituellement, 
     96   la méthode d'accès à l'index ne s'intérese pas à la provenance 
     97   des valeurs clés de l'index (ce sont toujours des valeurs clés 
     98   pré-traitées), mais trouve beaucoup d'intérêt aux informations de la classe 
     99   d'opérateur dans <structname>pg_index</structname>. Les entrées de ces deux 
     100   catalogues peuvent être accédées comme partie de la structure de données de 
     101   <structname>Relation</structname> passée à toute opération sur l'index. 
     102  </para> 
     103 
     104  <para> 
     105   Certaines colonnes d'options de <structname>pg_am</structname> ont des 
     106   implications peu évidentes. Les besoins de <structfield>amcanunique</structfield> 
    106107   sont discutés dans  <xref linkend="index-unique-checks"/>. 
    107    L'option <structfield>amcanmulticol</structfield> assure que la méthode 
    108    d'accès supporte les index multicolonnes alors que  
    109    <structfield>amoptionalkey</structfield> assure qu'il fera des parcours où 
    110    aucune clause indexable de restriction n'est donnée pour la première colonne 
     108   L'option <structfield>amcanmulticol</structfield> indique que la méthode 
     109   d'accès supporte les index multi-colonnes alors que  
     110   <structfield>amoptionalkey</structfield> indique que des parcours sont 
     111   autorisés lorsqu'aucune clause de restriction indexable n'est donnée pour la première colonne 
    111112   de l'index. Quand <structfield>amcanmulticol</structfield> est faux, 
    112113   <structfield>amoptionalkey</structfield> indique essentiellement si la méthode 
    113114   d'accès autorise les parcours complets de l'index sans clause de restriction. 
    114    Les méthodes d'accès qui supportent plusieurs colonnes d'index 
    115    <emphasis>doivent</emphasis> supporter les parcours omettant les restrictions d'une 
    116    ou de toutes les colonnes suivant la première&nbsp;; néanmoins, elles sont 
    117    autorisées à réclamer quelque restrictions pour apparaître  dès la première 
    118    colonne de l'index, et ceci est signalé en initialisant 
     115   Les méthodes d'accès qui supportent les colonnes d'index multiples 
     116   <emphasis>doivent</emphasis> supporter les parcours qui omettent des 
     117   restrictions sur une ou toutes les colonnes après la première&nbsp;; 
     118   néanmoins, elles peuvent imposées qu'une restriction apparaisse pour la 
     119   première colonne de l'index, ce qui est signalé par l'initialisation de 
    119120   <structfield>amoptionalkey</structfield> à faux. 
    120    <structfield>amindexnulls</structfield> assure que les index de l'entrée sont 
    121    créés pour les valeurs clés NULL. Comme la plupart des opérateurs indexables 
     121   <structfield>amindexnulls</structfield> indique que des entrées d'index sont 
     122   créées pour les valeurs de clés NULL. Comme la plupart des opérateurs indexables 
    122123   sont stricts et, du coup, ne peuvent pas renvoyer TRUE pour des entrées NULL, 
    123    il est à première vue attratif de ne pas stocker les entrées d'index pour les 
    124    valeurs NULL&nbsp;: de toute façon, elles ne peuvent pas être renvoyées par 
    125    un parcours d'index. Néanmoins, cet argument échoue quand un parcours d'index 
     124   il est à première vue attractif de ne pas stocker les entrées d'index pour les 
     125   valeurs NULL&nbsp;: un parcours d'index ne peut, de toute façon, pas les 
     126   retourner. Néanmoins, cet argument tombe lorsqu'un parcours d'index 
    126127   n'a pas de clause de restriction pour une colonne d'index donnée. En pratique, 
    127128   cela signifie que les index dont <structfield>amoptionalkey</structfield> vaut 
    128    true doivent indexer les valeurs NULL car le planificateur pourrait décider 
    129    d'utiliser un tel index sans clés parcourus. Une restriction relative est 
    130    qu'une méthode d'accès à l'index qui supporte plusieurs colonnes d'index 
    131    <emphasis>doit</emphasis> supporter l'indexage des valeurs NULL dans les colonnes 
    132    suivant la première car le planificateur supposera que l'index peut être 
     129   true doivent indexer les valeurs NULL, car le planificateur peut décider 
     130   d'utiliser un tel index sans aucune clé de parcours. Une restriction en 
     131   découle&nbsp;: une méthode d'accès qui supporte des colonnes d'index 
     132   multiples <emphasis>doit</emphasis> supporter l'indexage des valeurs NULL dans les colonnes 
     133   qui suivent la première, car le planificateur suppose que l'index peut être 
    133134   utilisé pour les requêtes qui ne restreignent pas ces colonnes. Par exemple, 
    134    considérez un index sur (a,b) et une requête avec <literal>WHERE a = 
    135    4</literal>. Le système supposera que l'index peut être utilisé pour les lignes 
    136    avec <literal>a = 4</literal>, ce qui est mauvais si l'index omet les lignes où 
    137    <literal>b</literal> est null. Néanmoins, il est correct d'omettre les lignes où la 
     135   si l'on considère un index sur (a,b) et une requête avec <literal>WHERE a = 
     136   4</literal>, le système suppose que l'index peut être utilisé pour 
     137   rechercher les lignes pour lesquelles <literal>a = 4</literal>, ce qui est 
     138   faux si l'index omet les lignes où <literal>b</literal> est null. 
     139   Néanmoins, il est correct d'omettre les lignes où la 
    138140   première colonne indexée est NULL. Du coup, 
    139141   <structfield>amindexnulls</structfield> doit valoir true seulement si la 
    140    méthode d'accès à l'index indexe toutes les lignes, ceci incluant les 
    141    combinaisons arbitraires des valeurs NULL. Une méthode d'accès d'index qui 
     142   méthode d'accès à l'index indexe toutes les lignes, en incluant les 
     143   combinaisons arbitraires de valeurs NULL. Une méthode d'accès d'index qui 
    142144   initialise <structfield>amindexnulls</structfield> peut aussi initialiser 
    143    <structfield>amsearchnulls</structfield>, indiquant ainsi qu'il supporte 
     145   <structfield>amsearchnulls</structfield>, indiquant ainsi qu'elle supporte 
    144146   les clauses <literal>IS NULL</literal> dans les conditions de recherche. 
    145147  </para> 
    …… 
    161163         IndexInfo *indexInfo); 
    162164</programlisting> 
    163    Construit un nouvel index. La relation de l'index a été créée physiquement 
    164    mais elle est vide. Elle doit être remplie avec les données fixes dont a besoin 
    165    la méthode d'accès, ainsi que les entrées pour toutes les lignes existant 
    166    déjà dans la table. D'habitude, la fonction <function>ambuild</function> appellera 
    167    <function>IndexBuildHeapScan()</function> pour parcourir la table avec les lignes 
    168    qui existent déjà et pour calculer les clés qui doivent être insérées dans 
     165   Construire un nouvel index. La relation de l'index a été créée physiquement 
     166   mais elle est vide. Elle doit être remplie avec toute donnée fixe nécessaire 
     167   à la méthode d'accès, ainsi que les entrées pour toutes les lignes existant 
     168   déjà dans la table. Habituellement, la fonction <function>ambuild</function> appelle 
     169   <function>IndexBuildHeapScan()</function> pour parcourir la table à la 
     170   recherche des lignes qui existent déjà et calculer les clés à insérer dans 
    169171   l'index. La fonction doit renvoyer une structure allouée par palloc contenant 
    170    les statistiques sur le nouvel index. 
    171   </para> 
    172  
     172   les statistiques du nouvel index. 
     173  </para> 
     174 
     175<!-- SAS::ICI --> 
    173176  <para> 
    174177<programlisting>bool 
    …… 
    180183          bool check_uniqueness); 
    181184</programlisting> 
    182    Insère une nouvelle ligne dans un index existant. Les tableaux 
     185   Insérer une nouvelle ligne dans un index existant. Les tableaux 
    183186   <literal>values</literal> et <literal>isnull</literal> donnent les valeurs clés à indexer. 
    184187   <literal>heap_tid</literal> est le TID à indexer. Si la méthode d'accès supporte les 
    185188   index uniques (son drapeau <structname>pg_am</structname>.<structfield>amcanunique</structfield> 
    186    vaut true), alors <literal>check_uniqueness</literal> pourrait aussi valoir true, 
     189   vaut true), alors <literal>check_uniqueness</literal> peut aussi valoir true, 
    187190   auquel cas la méthode d'accès doit vérifier qu'il n'y a pas de lignes en 
    188191   conflit&nbsp;; c'est la seule situation dans laquelle la méthode d'accès a 

  • traduc/trunk/postgresql/info.xml

    r973 r1156  
    1717    <listitem> 
    1818     <para> 
    19       La FAQ <indexterm><primary>FAQ</primary></indexterm> contient des réponses 
    20       mises à jours continuellement pour les questions les plus fréquentes. 
     19      La FAQ <indexterm><primary>FAQ</primary></indexterm> contient des 
     20      réponses, mises à jours en continu, aux questions les plus fréquentes. 
    2121     </para> 
    2222    </listitem> 
    …… 
    2929      Le <ulink url="http://www.postgresql.org">site web</ulink> de 
    3030      <productname>PostgreSQL</productname> contient des détails sur la 
    31       dernière version, et bien d'autres informations pour rendre son travail 
    32       ou son investissement personnel avec 
     31      dernière version, et bien d'autres informations pour rendre travail 
     32      ou investissement personnel avec 
    3333      <productname>PostgreSQL</productname> plus productif. 
    3434     </para> 
    …… 
    4040    <listitem> 
    4141     <para> 
    42       Les listes de discussion constituent un bon endroit pour trouver une 
    43       réponse à ses questions, pour partager ses expériences avec celles 
     42      Les listes de discussion constituent un bon endroit pour trouver des 
     43      réponses à ses questions, pour partager ses expériences avec celles 
    4444      d'autres utilisateurs et pour contacter les développeurs. La consultation 
    45       du site web de <productname>PostgreSQL</productname> apportera tous les détails. 
     45      du site web de <productname>PostgreSQL</productname> fournit tous les détails. 
    4646     </para> 
    4747    </listitem>