[Trad] [svn:pgfr] r1198 - traduc/trunk/postgresql
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Mar 18 Nov 18:35:23 CET 2008
Author: sas
Date: 2008-11-18 18:35:23 +0100 (Tue, 18 Nov 2008)
New Revision: 1198
Modified:
traduc/trunk/postgresql/indices.xml
Log:
D?\195?\169but de relecture
Modified: traduc/trunk/postgresql/indices.xml
===================================================================
--- traduc/trunk/postgresql/indices.xml 2008-11-05 22:47:24 UTC (rev 1197)
+++ traduc/trunk/postgresql/indices.xml 2008-11-18 17:35:23 UTC (rev 1198)
@@ -12,9 +12,9 @@
</indexterm>
<para>
- Les index sont une méthode courante pour augmenter les performances
+ L'utilisation d'index est une façon habituelle d'améliorer 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.
+ retrouver une ligne spécifique bien plus rapidement.
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>
@@ -24,40 +24,40 @@
<title>Introduction</title>
<para>
- Supposons que nous ayons une table comme celle-ci :
+ Soit une table définie ainsi :
<programlisting>CREATE TABLE test1 (
id integer,
contenu varchar
);</programlisting>
- et que l'application utilise beaucoup de requêtes de la forme :
+ et une application qui utilise beaucoup de requêtes de la forme :
<programlisting>SELECT contenu FROM test1 WHERE id = <replaceable>constante</replaceable>;</programlisting>
- Sans préparation supplémentaire, le système devrait lire la table
- <structname>test1</structname> en entier, ligne par ligne, pour trouver
+ Sans préparation, le système doit lire la table
+ <structname>test1</structname> dans son intégralité, 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
+ <structname>test1</structname>, et que seules 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
+ Mais si le système maintient 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
+ beaucoup plus efficace pour trouver les lignes recherchées.
+ Il se peut qu'il n'ait ainsi qu'à parcourir 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
+ que ceux de fiction : les termes et concepts 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
+ (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 sont avantageux.
+ responsabilité du programmeur de prévoir les index qui sont avantageux.
</para>
<para>
La commande suivante permet de créer un index sur la colonne
- <structfield>id</structfield> dont nous parlons :
+ <structfield>id</structfield> :
<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
@@ -65,7 +65,7 @@
</para>
<para>
- Pour supprimer l'index, utilisez la commande <command>DROP INDEX</command>.
+ Pour supprimer l'index, on utilise la commande <command>DROP INDEX</command>.
Les index peuvent être ajoutés et retirés des tables à tout moment.
</para>
@@ -84,7 +84,7 @@
<para>
Les index peuvent aussi bénéficier aux commandes
- <command>UPDATE</command> et <command>DELETE</command> qui ont des
+ <command>UPDATE</command> et <command>DELETE</command> à
conditions de recherche. De plus, les index peuvent ê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
@@ -94,12 +94,12 @@
<para>
Créer un index sur une grosse table peut prendre beaucoup de temps. Par
défaut, <productname>PostgreSQL</productname> autorise la lecture (SELECT)
- sur la table pendant la création d'un index sur celle-ci mais interdit les
- écritures (INSERT, UPDATE, DELETE) qui sont bloquées jusqu'à la fin de la
- construction de l'index. Dans des environnements de production, ceci est
+ sur la table pendant la création d'un index sur celle-ci, mais interdit les
+ écritures (INSERT, UPDATE, DELETE). Elles sont bloquées jusqu'à la fin de la
+ construction de l'index. Dans des environnements de production, c'est
souvent inacceptable. Il est possible d'autoriser les écritures en
- parallèle de la création d'un index mais quelques précautions sont à
- prendre en considération. Pour plus d'informations, voir <xref
+ parallèle de la création d'un index, mais quelques précautions sont à
+ prendre. Pour plus d'informations, voir <xref
linkend="sql-createindex-concurrently"
endterm="sql-createindex-concurrently-title"/>.
</para>
@@ -120,7 +120,7 @@
<productname>PostgreSQL</productname> propose plusieurs types d'index :
B-tree, Hash, GiST et GIN. Chaque type d'index utilise un algorithme
différent qui convient à un type particulier de requêtes. Par défaut, la
- commande <command>CREATE INDEX</command> créera un index B-tree, ce qui
+ commande <command>CREATE INDEX</command> crée un index B-tree, ce qui
convient dans la plupart des situations.
<indexterm>
<primary>index</primary>
@@ -130,10 +130,10 @@
<primary>B-tree</primary>
<see>index</see>
</indexterm>
- Les index B-tree savent traiter les égalités et les recherches sur des
- tranches de valeurs des données qui peuvent être triées. En particulier,
+ Les index B-tree savent traiter les requêtes d'égalité et par
+ tranches sur des données qu'il est possible de trier. En particulier,
l'optimiseur de requêtes de <productname>PostgreSQL</productname>
- essaie d'utiliser un index B-tree lorsque une colonne indexée est
+ considère l'utilisation d'un index B-tree lorsqu'une colonne indexée est
utilisée dans une comparaison qui utilise un de ces opérateurs :
<simplelist>
@@ -146,8 +146,8 @@
Les constructions équivalentes à des combinaisons de ces opérateurs, comme
<literal>BETWEEN</literal> et <literal>IN</literal>, peuvent aussi être
- implémentées avec une recherche par index B-tree. De plus, une condition
- <literal>IS NULL</literal> sur une colonne indexée peut être utilisé avec
+ implantées avec une recherche par index B-tree. Une condition
+ <literal>IS NULL</literal> sur une colonne indexée peut aussi être utilisé avec
un index B-tree.
</para>
@@ -157,12 +157,12 @@
et <literal>~</literal> <emphasis>si</emphasis> le motif est une constante et
se trouve 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 locale C, il vous faudra créer l'index avec
- une classe d'opérateur spéciale pour supporter l'indexage à correspondance
+ pas <literal>col LIKE '%bar'</literal>. Toutefois, si le serveur
+ n'utilise pas la locale C, il est nécessaire de créer l'index avec
+ une classe d'opérateur spéciale pour supporter l'indexation à correspondance
de modèles. Voir la <xref linkend="indexes-opclass"/> ci-dessous. Il est
aussi possible d'utiliser des index B-tree pour <literal>ILIKE</literal> et
- <literal>~*</literal> mais seulement si le modèle commence avec des caractères
+ <literal>~*</literal>, mais seulement si le modèle débute par des caractères
non alphabétiques, c'est-à-dire des caractères non affectés par les
conversions majuscules/minuscules.
</para>
@@ -176,11 +176,11 @@
<primary>hash</primary>
<see>index</see>
</indexterm>
- Les index hash peuvent seulement gérer des comparaisons d'égalité simple.
- Le planificateur de requêtes considérera l'utilisation d'un index hash quand
+ Les index hash ne peuvent gérer que des comparaisons d'égalité simple.
+ Le planificateur de requêtes considère l'utilisation d'un index hash quand
une colonne indexée est impliquée dans une comparaison avec l'opérateur
<literal>=</literal>. (Mais les index hash ne supportent pas les recherches
- de type <literal>IS NULL</literal> .) La commande suivante est utilisée pour
+ de type <literal>IS NULL</literal>.) La commande suivante est utilisée pour
créer un index hash :
<synopsis>CREATE INDEX <replaceable>nom</replaceable> ON <replaceable>table</replaceable> USING hash (<replaceable>column</replaceable>);
</synopsis>
@@ -188,12 +188,14 @@
<note>
<para>
- Les tests ont montré que les index hash de <productname>PostgreSQL</productname>
- ne réalisent pas mieux que les index B-tree. La taille de l'index et son
- temps de construction sont bien pires. De plus, les opérations d'index hash
- ne sont pas tracées par les WAL, donc les index hash peuvent avoir besoin
- d'être reconstruit avec <command>REINDEX</command> après un crash de la base.
- Pour ces raisons, l'utilisation des index hash est découragée.
+ Les tests ont montré que les index de hachage (<forreignphrase>hash
+ index</foreignphrase>) de <productname>PostgreSQL</productname>
+ n'offrent pas de meilleure performance que les index B-tree. De plus, la
+ taille de l'index et son temps de construction sont bien pires. D'autre
+ part, les opérations sur les index de hachage
+ ne sont pas tracées par les WAL. Il est dont généralement nécessaire de
+ les reconstruire avec <command>REINDEX</command> après un crash de la base.
+ Pour ces raisons, l'utilisation des index de hachage est découragée.
</para>
</note>
@@ -206,13 +208,13 @@
<primary>GiST</primary>
<see>index</see>
</indexterm>
- Les index GiST ne sont pas un seul type d'index mais plutôt une infrastructure
- à l'intérieur duquel plusieurs stratégies d'indexage peuvent être implémentées.
+ Les index GiST ne constituent pas un unique type d'index, mais plutôt une infrastructure
+ à l'intérieur de laquelle plusieurs stratégies d'indexage peuvent être implantées.
De cette façon, les opérateurs particuliers avec lesquels un index GiST peut
- être utilisé varient suivant la stratégie d'indexage (la <firstterm>classe
- d'opérateur</firstterm>). Comme exemple, la distribution standard de
+ être utilisé varient en fonction de la stratégie d'indexage (la <firstterm>classe
+ d'opérateur</firstterm>). Par exemple, la distribution standard de
<productname>PostgreSQL</productname> inclut des classes d'opérateur GiST
- pour plusieurs types de données géométiques à deux dimensions, qui supportent
+ pour plusieurs types de données géométriques à deux dimensions, qui supportent
des requêtes indexées utilisant ces opérateurs :
<simplelist>
@@ -249,10 +251,10 @@
<see>index</see>
</indexterm>
Les index GIN sont des index inversés qui peuvent gérer des valeurs contenant
- plus d'une clé, les tableaux par exemple. Comme GiST, GIN peut supporter
- plusieurs stratégies différentes d'indexage définies par l'utilisateur. Les
+ plusieurs clés, les tableaux par exemple. Comme GiST, GIN supporte
+ différentes stratégies d'indexation utilisateur. Les
opérateurs particuliers avec lesquels un index GIN peut être utilisé varient
- suivant la stratégie d'indexage. Comme exemple, la distribution standard de
+ selon la stratégie d'indexation. Par exemple, la distribution standard de
<productname>PostgreSQL</productname> inclut des classes d'opérateurs GIN pour
des tableaux à une dimension qui supportent les requêtes indexées utilisant
ces opérateurs :
@@ -283,77 +285,83 @@
</indexterm>
<para>
- Un index peut porter sur plus d'une colonne d'une table. Par exemple, si vous avez
- une table de cette forme :
+ Un index peut porter sur plusieurs colonnes d'une table. Soit, par exemple,
+ une table de la forme :
<programlisting>CREATE TABLE test2 (
majeur int,
mineur int,
nom varchar
);</programlisting>
- (par exemple, si vous gardez votre répertoire
+ (cas d'un utilisateur gardant son répertoire
<filename class="directory">/dev</filename> dans une base de données...)
- et que vous faites fréquemment des requêtes comme :
+ et que 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
+ sont fréquemment exécutées. Il peut alors être souhaitable de définir un
+ index qui porte sur les deux colonnes
<structfield>majeur</structfield> et
- <structfield>mineur</structfield> ensemble, par exemple avec :
+ <structfield>mineur</structfield>. Ainsi, par exemple :
<programlisting>CREATE INDEX test2_mm_idx ON test2 (majeur, mineur);</programlisting>
</para>
<para>
Actuellement, seuls les types d'index B-trees et GiST supportent les
- index multicolonnes. Un maximum de 32 colonnes peut être indexé.
+ index multicolonnes. 32 colonnes peuvent être précisées, au maximum.
Cette limite peut être modifiée à la compilation de
- <productname>PostgreSQL</productname>. Voyez le fichier
+ <productname>PostgreSQL</productname>. Voir le fichier
<filename>pg_config_manual.h</filename>.
</para>
<para>
- Un index B-tree multicolonnes peut être utilisé avec des conditions de
- requêtes qui impliquent tout sous-ensemble des colonnes de l'index mais
- ce dernier est le plus efficace quant il s'agit des contraintes des
- premières colonnes (celles de gauche). La règle exacte est que les
- contraintes d'égalité sur les premières colonnes, plus toute contrainte
- de différence sur la première colonne qui n'a pas une contrainte d'égalité
- seront utilisées pour limiter la partie parcourue de l'index. Les contraintes
- sur les colonnes à droite de ces colonnes sont vérifiées dans l'index, donc
- elles évitent des visites de la table mais elles ne réduisent pas la partie
- de l'index à parcourir. Par exemple, avec un index sur
+ Un index B-tree multicolonne peut être utilisé avec des conditions de
+ requêtes impliquant un sous-ensemble quelconque de colonnes de l'index.
+ L'index est toutefois plus efficace lorsqu'il y a des contraintes sur les
+ premières colonnes (celles de gauche).
+ La règle exacte est la suivante : les
+ contraintes d'égalité sur les premières colonnes, et toute contrainte
+ d'inégalité sur la première colonne qui ne possède pas de contrainte d'égalité
+ sont utilisées pour limiter la partie parcourue de l'index. Les contraintes
+ sur les colonnes à droite de ces colonnes sont vérifiées dans l'index, et
+ limitent ainsi les visites de la table, mais elles ne réduisent pas la partie
+ de l'index à parcourir.
+ </para>
+
+ <para>
+ Par exemple, avec un index sur
<literal>(a, b, c)</literal> et une condition de requête <literal>WHERE a =
- 5 AND b >= 42 AND c < 77</literal>, l'index devrait être parcouru à partir de
- la première entrée avec <literal>a</literal> = 5 et <literal>b</literal> = 42 jusqu'à la
- dernière entrée de <literal>a</literal> = 5. Les entrées de l'index avec
- <literal>c</literal> >= 77 seront passées mais elles devront toujours être
- parcourues. En principe, cet index pourrait être utilisé pour les requêtes
+ 5 AND b >= 42 AND c < 77</literal>, l'index est parcouru à partir de
+ la première entrée pour laquelle <literal>a</literal> = 5 et <literal>b</literal> = 42 jusqu'à la
+ dernière entrée pour laquelle <literal>a</literal> = 5. Les entrées de l'index avec
+ <literal>c</literal> >= 77 sont sautées, mais elles sont toujours
+ parcourues. En principe, cet index peutt être utilisé pour les requêtes
qui ont des contraintes sur <literal>b</literal> et/ou <literal>c</literal> sans contrainte
- sur <literal>a</literal> — mais l'index entier devra être parcouru, donc, dans
- la plupart des cas, le planificateur préférera un parcours séquentiel de la
- table plutôt que d'utiliser l'index.
+ sur <literal>a</literal> — mais l'index entier doit être parcouru, donc, dans
+ la plupart des cas, le planificateur préfère un parcours séquentiel de la
+ table à l'utilisation de l'index.
</para>
<para>
- Un index GiST multicolonnes peut être utilisé avec des conditions dans la
- requête qui impliquent tout sous-ensemble des colonnes de l'index. Les
- conditions sur les colonnes supplémentaires restreignent les entrées renvoyées
- par l'index mais la condition sur la première colonne est la plus importante
- pour déterminer la quantité d'index qui sera parcourue. Un index GiST sera
- relativement inefficace si sa première colonne a seulement quelques valeurs
+ Un index GiST multicolonne peut être utilisé avec des conditions de
+ requête qui impliquent un sous-ensemble quelconque de colonnes de l'index. Les
+ conditions sur des colonnes supplémentaires restreignent les entrées renvoyées
+ par l'index, mais la condition sur la première colonne est la plus importante
+ pour déterminer la part de l'index parcourue. Un index GiST est
+ relativement inefficace si sa première colonne n'a que quelques valeurs
distinctes, même s'il y a beaucoup de valeurs distinctes dans les colonnes
supplémentaires.
</para>
<para>
- Bien sûr, chaque colonne doit être utilisée avec les opérateurs appropriés
+ Chaque colonne doit évidemment être utilisée avec des opérateurs appropriés
au type de l'index ; les clauses qui impliquent d'autres opérateurs ne
- seront pas pris en compte.
+ sont pas pris en compte.
</para>
<para>
- Les index multicolonnes devraient être utilisés avec parcimonie. Dans la
- plupart des cas, un index sur une seule colonne est suffisant et sauvegarde
- de l'espace et du temps. Les index avec plus de trois colonnes ont un gros
- risque d'être inefficace sauf si l'utilisation de cette table est extrêmement
- stylisée. Voir aussi la <xref linkend="indexes-bitmap-scans"/> pour des
+ Il est préférable d'utiliser les index multicolonnes avec parcimonie. Dans la
+ plupart des cas, un index sur une seule colonne est suffisant et préserve
+ espace et temps. Les index de plus de trois colonnes risquent fort
+ d'être inefficaces, sauf si l'utilisation de cette table est extrêmement
+ stylisée. Voir aussi la <xref linkend="indexes-bitmap-scans"/> pour les
discussions sur les mérites des différentes configurations d'index.
</para>
</sect1>
@@ -368,17 +376,18 @@
</indexterm>
<para>
- En plus de trouver simplement les lignes à renvoyer à une requête, un index
- peut être capable de les renvoyer dans un ordre spécifique. Ceci permet
- le respect d'une clause <literal>ORDER BY</literal> sans nécessiter une
+ Au delà du simple fait de trouver les lignes à renvoyer à une requête, un index
+ peut les renvoyer dans un ordre spécifique. Cela permet de résoudre une
+ clause <literal>ORDER BY</literal> sans
étape de tri séparée. De tous les types d'index actuellement supportés par
<productname>PostgreSQL</productname>, seuls les B-tree peuvent produire une
sortie triée — les autres types d'index renvoient les lignes
- correspondantes dans un ordre non spécifié, dépendant de l'implémentation.
+ correspondantes dans un ordre imprécis, dépendant de l'implantation.
</para>
+<!-- SAS::ICI -->
<para>
- Le planificateur considérera qu'une clause <literal>ORDER BY</literal> est
+ Le planificateur considère qu'une clause <literal>ORDER BY</literal> est
satisfaite soit en parcourant tout index disponible qui correspond à la
clause soit en parcourant la table dans l'ordre physique et en réalisant
un tri explicite. Pour une requête qui nécessite une fraction importante
More information about the Trad
mailing list