[Trad] [svn:pgfr] r1213 - traduc/trunk/postgresql
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Mer 17 Déc 11:10:25 CET 2008
Author: sas
Date: 2008-12-17 11:10:24 +0100 (Wed, 17 Dec 2008)
New Revision: 1213
Modified:
traduc/trunk/postgresql/indices.xml
Log:
Relecture OK
close #43
close #184
Modified: traduc/trunk/postgresql/indices.xml
===================================================================
--- traduc/trunk/postgresql/indices.xml 2008-12-16 20:42:30 UTC (rev 1212)
+++ traduc/trunk/postgresql/indices.xml 2008-12-17 10:10:24 UTC (rev 1213)
@@ -512,41 +512,43 @@
et peuvent être utilisés.
</para>
- <!-- SAS::ICI -->
<para>
- Dans toutes les applications un peu compliquées, il existe différentes
- combinaisons d'index qui pourraient être utiles. Le développeur de la base
- de données doit faire des concessions pour décider des index à fournir.
- Quelque fois, des index à colonnes multiples sont préférables mais quelque
- fois, il est mieux de créer des index séparés et de dépendre de la
- fonctionnalité des index combinés. Par exemple, si votre temps de travail
- inclut un mixe des requêtes qui impliquent parfois seulement la colonne
- <literal>x</literal>, quelque fois seulement la colonne <literal>y</literal> et quelque
- fois les deux colonnes, vous pourriez choisir deux index séparés sur
- <literal>x</literal> et <literal>y</literal>, en vous reposant sur la combinaison d'index
- pour traiter les requêtes qui utilisent les deux colonnes. Vous pouvez aussi
- créer un index multicolonne sur <literal>(x, y)</literal>. Cet index serait
+ Le nombre de combinaisons d'index possibles croît parallèlement à la
+ complexité des applications. Il est alors de la responsabilité du
+ développeur de la base de décider des index à fournir. Il est quelques fois
+ préférable de créer des index multi-colonnes, mais il est parfois préférable
+ de créer des index séparés et de s'appuyer sur la fonctionnalité de
+ combinaison des index.
+ </para>
+ <para>
+ Par exemple, si la charge inclut un mélange de requêtes qui impliquent
+ parfois uniquement la colonne <literal>x</literal>, parfois uniquement
+ la colonne <literal>y</literal> et quelques
+ fois les deux colonnes, on peut choisir deux index séparés sur
+ <literal>x</literal> et <literal>y</literal> et s'appuyer sur la combinaison d'index
+ pour traiter les requêtes qui utilisent les deux colonnes. On peut aussi
+ créer un index multi-colonnes sur <literal>(x, y)</literal>. Cet index est
typiquement plus efficace que la combinaison d'index pour les requêtes
impliquant les deux colonnes mais, comme discuté dans la <xref
- linkend="indexes-multicolumn"/>, il serait pratiquement inutile pour les
- requêtes impliquant seulement <literal>y</literal>, donc il ne peut pas être le
- seul index. Une combinaison de l'index multicolonnes et d'un index séparé
- sur <literal>y</literal> serviraient raisonnablement. Pour les requêtes impliquant
- seulement <literal>x</literal>, l'index multicolonne pourrait être utilisé bien
- qu'il soit plus large et donc plus lent qu'un index sur <literal>x</literal> seul.
- La dernière alternative est de créer les trois index mais ceci est
- probablement seulement raisonnable si la table est parcourue bien plus
- fréquemment qu'elle n'est mise à jour et les trois types de requête sont
+ linkend="indexes-multicolumn"/>, il est pratiquement inutile pour les
+ requêtes n'impliquant que <literal>y</literal>. Il ne peut donc pas être le
+ seul index. Une combinaison de l'index multi-colonnes et d'un index séparé
+ sur <literal>y</literal> est une solution raisonnable. Pour les requêtes qui
+ n'impliquent que <literal>x</literal>, l'index multi-colonnes peut être
+ utilisé, bien qu'il soit plus large et donc plus lent qu'un index sur <literal>x</literal> seul.
+ La dernière alternative consiste à créer les trois index, mais cette
+ solution n'est raisonnable que si la table est lue bien plus
+ fréquemment qu'elle n'est mise à jour et que les trois types de requête sont
communs. Si un des types de requête est bien moins courant que les autres,
- vous devriez probablement en rester à la création des deux seuls index qui
- correspondront le mieux aux types communs.
+ il est préférable de ne créer que les deux index qui
+ correspondent le mieux aux types communs.
</para>
</sect1>
<sect1 id="indexes-unique">
- <title>Index uniques</title>
+ <title>Index d'unicité</title>
<indexterm zone="indexes-unique">
<primary>index</primary>
@@ -562,28 +564,28 @@
</para>
<para>
- Lorsqu'un index est déclaré unique, des lignes différentes d'une table ne
- pourront avoir une valeur égale. Les valeurs NULL ne sont pas
- considérées comme égales. Un index unique multicolonnes ne rejette que les
+ Lorsqu'un index est déclaré unique, il ne peut exister plusieurs lignes
+ d'une table qui possèdent la même valeur indexée. Les valeurs NULL ne sont pas
+ considérées égales. Un index d'unicité multi-colonnes ne rejette 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
+ d'unicité à la déclaration d'une contrainte d'unicité ou d'une clé primaire
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.
+ ou la contrainte d'unicité (au besoin, il s'agit d'un index multi-colonnes).
+ C'est cet index qui assure le mécanisme de vérification de 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, cependant, savoir qu'il n'est pas nécessaire de créer manuellement
- un index sur les colonnes uniques. Cela dupliquerait l'index créé
+ index pour vérifier les contraintes d'unicité peut être considérée comme
+ un détail d'implantation qui ne doit pas être utilisé directement.
+ Il n'est pas nécessaire de créer manuellement
+ un index sur les colonnes uniques. Cela duplique l'index créé
automatiquement.
</para>
</note>
@@ -591,11 +593,11 @@
<sect1 id="indexes-expressional">
- <title>Index sur des expressions</title>
+ <title>Index d'expressions</title>
<indexterm zone="indexes-expressional">
<primary>index</primary>
- <secondary sortas="expressions">sur des expressions</secondary>
+ <secondary sortas="expressions">sur expressions</secondary>
</indexterm>
<para>
@@ -603,7 +605,7 @@
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
- en se basant sur les résultat des calculs.
+ en utilisant les résultat de calculs.
</para>
<para>
@@ -612,29 +614,30 @@
<programlisting>SELECT * FROM test1 WHERE lower(col1) = 'valeur';</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 :
+ Un tel 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 être définies avec une simple
- contrainte.
+ Si l'index est déclaré <literal>UNIQUE</literal>, il empêche
+ la création de lignes dont les valeurs de la colonne <literal>col1</literal> ne
+ diffèrent que par la casse, ainsi que celle de lignes dont les valeurs de la
+ colonne <literal>col1</literal> sont identiques.
+ Ainsi, les index d'expressions peuvent être utilisés pour
+ appliquer des contraintes qui ne peuvent être définies avec une simple
+ contrainte d'unicité.
</para>
<para>
- Un autre exemple, si vous faites souvent des requêtes comme celle-ci :
+ Autre exemple. Lorsque des requêtes comme :
<programlisting>SELECT * FROM personnes WHERE (prenom || ' ' || nom) = 'Jean Dupont';</programlisting>
- alors il peut être utile de créer un index comme celui-ci :
+ sont fréquentes, alors il peut être utile de créer un index comme :
<programlisting>CREATE INDEX personnes_noms ON personnes ((prenom || ' ' || nom));</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
+ de mettre des parenthèses autour de l'expression indexée, comme dans
l'exemple précédent. Les parenthèses peuvent être omises quand l'expression
est un simple appel de fonction, comme dans le premier exemple.
</para>
@@ -642,14 +645,14 @@
<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. Néanmoins, les expressions d'index ne sont
- <emphasis>pas</emphasis> recalculés lors d'une recherche par index car ils sont
+ ligne. Néanmoins, les expressions d'index ne sont
+ <emphasis>pas</emphasis> recalculées lors d'une recherche par index car elles sont
déjà stockés dans l'index. Dans les deux exemples ci-dessus, le système
- voit la requête comme un <literal>WHERE colonne_indexée = 'constante'</literal>
- et, du coup, la rapidité de la recherche est équivalente à une autre simple
- recherche d'index. Du coup, les index avec des expressions sont utiles
- quand la rapidité de la recherche est plus importante que la rapidité de
- l'insertion et de la mise à jour.
+ voit la requête comme un <literal>WHERE colonne_indexée =
+ 'constante'</literal>. De ce fait, la recherche est aussi rapide que toute
+ autre requête d'index. Ainsi, les index d'expressions sont utiles
+ lorsque la rapidité de recherche est plus importante que la rapidité
+ d'insertion et de mise à jour.
</para>
</sect1>
@@ -665,41 +668,40 @@
<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
+ conditionnelle (appelée <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. Les index partiels sont une fonctionnalité
- spécialisée mais il existe plusieurs situations où ils sont utiles.
+ spécialisée, mais ils trouvent leur utilité dans de nombreuses situations.
</para>
<para>
- Une raison majeure pour l'utilisation principale 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
+ Une raison majeure à l'utilisation d'index partiels est d'éviter
+ d'indexer les valeurs courantes. Puisqu'une requête qui recherche une
+ valeur courante (qui correspond à plus de quelques
+ pourcents de toutes les lignes) n'utilise, de toute façon, pas cet index, 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 nombre
+ d'opérations de mise à jour de la table, car l'index n'a pas à être
mis à jour à chaque fois. L'<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>
+ <title>Mettre en place un index partiel pour exclure des 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érieurs, vous n'avez probablement pas besoin d'indexer les classes
- d'adresses IP qui correspondent au sous-réseau de votre organisation.
+ Soit l'enregistrement d'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 à
+ l'organisation, mais certaines proviennent de l'extérieur (des employés connectés
+ par modem, par exemple).
+ Si les recherches par adresses IP concernent essentiellement les accès
+ extérieurs, il est inutile d'indexer les classes
+ d'adresses IP qui correspondent au sous-réseau de l'organisation.
</para>
<para>
- Supposons que la table soit comme ceci :
+ Si la table ressemble à :
<programlisting>CREATE TABLE access_log (
url varchar,
client_ip inet,
@@ -708,70 +710,70 @@
</para>
<para>
- Pour créer un index partiel qui corresponde à notre exemple, il faut utiliser
+ Pour créer un index partiel qui corresponde à l'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 pouvant utiliser cet index est :
+ 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 ce type d'index partiel nécessite que les valeurs courantes
+ Ce 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
+ (du fait de la nature de l'application) et statique (ne change 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 pour modifier la définition de l'index de temps en temps.
</para>
</example>
<para>
- Une autre utilisation possible d'un index partiel revient à exclure des
+ Une autre utilisation possible d'index partiel revient à exclure des
valeurs de l'index qui ne correspondent pas aux requêtes courantes ;
ceci est montré dans l'<xref linkend="indexes-partial-ex2"/>. Cette méthode
- donne les mêmes avantages que la précédente mais empêche l'accès aux valeurs
+ donne les mêmes avantages que la précédente mais empêche l'accès par l'index aux valeurs
<quote>sans intérêt</quote>. Évidemment, mettre en place des index partiels
- pour ce genre de scénario nécessite beaucoup de soin et d'expérimentation.
+ pour ce genre de scénarios 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 utilisées, alors vous pouvez améliorer les
+ Soit une table qui contient des commandes facturées et des
+ commandes non facturées, avec les commandes non facturées qui ne prennent
+ qu'une petite fraction de l'espace dans la table, et qu'elles sont les
+ plus accédées. Il est possible d'améliorer les
performances en créant un index limité aux lignes non facturées.
- La commande pour créer l'index ressemblerait à ceci :
+ La commande pour créer l'index ressemble à :
<programlisting>CREATE INDEX index_commandes_nonfacturees ON commandes (no_commande)
WHERE facturee is not true;</programlisting>
</para>
<para>
- La requête suivante utilise probablement cet index :
+ La requête suivante utilise cet index :
<programlisting>SELECT * FROM commandes WHERE facturee is not true AND no_commande < 10000;</programlisting>
Néanmoins, l'index peut aussi être utilisé dans des requêtes qui
n'utilisent pas <structfield>no_commande</structfield>, comme :
<programlisting>SELECT * FROM commandes WHERE facturee is not true AND montant > 5000.00;</programlisting>
Ceci n'est pas aussi efficace qu'un index partiel sur la colonne
- <structfield>montant</structfield> car le système doit lire l'index en entier.
+ <structfield>montant</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.
+ plus efficace.
</para>
<para>
- Notez que cette requête ne peut pas utiliser cet index :
+ La requête suivante ne peut pas utiliser cet index :
<programlisting>SELECT * FROM commandes WHERE no_commande = 3501;</programlisting>
La commande 3501 peut faire partie des commandes facturées ou
- bien des commandes non facturées.
+ non facturées.
</para>
</example>
@@ -788,40 +790,41 @@
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
+ 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 < 1</quote> implique <quote>x < 2</quote> ; sinon,
+ exemple <quote>x < 1</quote> implique <quote>x < 2</quote> ;
+ dans les autres cas,
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. La correspondance prend place lors de l'exécution
- de la planification de la requpete, pas lors de l'exécution. À ce titre, les
- clauses de requêtes à paramètres ne fonctionneront pas avec un index partiel.
- Par exemple, une requête préparée avec un paramètre pourrait indiquer
- <quote>x < ?</quote> qui n'impliquerait jamais
+ clause <literal>WHERE</literal> de la requête, sans quoi l'index ne peut pas
+ être considéré utilisable. La correspondance prend place lors de l'exécution
+ de la planification de la requête, pas lors de l'exécution. À ce titre, les
+ clauses de requêtes à paramètres ne fonctionnent pas avec un index partiel.
+ Par exemple, une requête préparée avec un paramètre peut indiquer
+ <quote>x < ?</quote> qui n'implique jamais
<quote>x < 2</quote> pour toutes les valeurs possibles du paramètre.
</para>
<para>
- Le troisième usage possible des index partiels ne nécessite pas que
+ Un 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 l'<xref
- linkend="indexes-partial-ex3"/>. Ceci permet de mettre en place une unicité
+ d'unicité sur un sous-ensemble de la table, comme dans l'<xref
+ linkend="indexes-partial-ex3"/>. Cela 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>
+ <title>Mettre en place un index d'unicité 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
+ Soit une table qui décrit des résultats de tests.
+ On souhaite s'assurer qu'il n'y a qu'une seule entrée
<quote>succès</quote> (succes) pour chaque combinaison de sujet et de
- résultat, mais il peut y avoir un nombre quelconque d'entrées
- <quote>echec</quote>. Voici une façon de le faire.
+ résultat, alors qu'il peut y avoir un nombre quelconque d'entrées
+ <quote>echec</quote>. Une façon de procéder :
<programlisting>CREATE TABLE tests (
sujet text,
resultat text,
@@ -831,30 +834,30 @@
CREATE UNIQUE INDEX contrainte_tests_reussis ON tests (sujet, resultat)
WHERE succes;</programlisting>
- C'est une méthode très efficace pour le faire quand il y a peu de tests
+ C'est une méthode très efficace 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 les
+ Enfin, un index partiel peut aussi être utilisé pour surcharger les
choix de plan d'exécution de requête du système.
- De plus, les jeux de données particuliers peuvent faire que le
- système utilise un index alors qu'il ne devrait vraiment pas le faire.
+ De plus, des jeux de données à distribution particulière peuvent inciter le
+ système à utiliser un index alors qu'il ne devrait pas.
Dans ce cas, on peut mettre en place l'index de telle façon 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'utilisation de l'index.
- En fait, les choix de plan d'exécution grossièrement incorrects doivent
+ n'est pas nécessaire pour éviter l'utilisation de l'index.
+ En fait, les choix de plan d'exécution 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.
+ Mettre en place un index partiel indique une connaissance au
+ moins aussi étendue que celle de l'analyseur de requêtes,
+ en particulier, savoir 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
@@ -862,8 +865,8 @@
</para>
<para>
- Vous trouverez plus d'informations sur les index partiels
- en lisant <xref linkend="ston89b"/>, <xref linkend="olson93"/>
+ Plus d'informations sur les index partiels
+ est disponible dans <xref linkend="ston89b"/>, <xref linkend="olson93"/>
et <xref linkend="seshadri95"/>.
</para>
</sect1>
@@ -886,17 +889,17 @@
<synopsis>CREATE INDEX <replaceable>nom</replaceable> ON <replaceable>table</replaceable> (<replaceable>colonne</replaceable> <replaceable>classe_operateur</replaceable> <optional><replaceable>options de tri</replaceable></optional><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>.
+ <type>int4</type> utilise 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
+ colonne est généralement suffisante. Les classes d'opérateurs sont utiles pour
+ certains types de données, pour lesquels il peut 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.
+ Par exemple, une donnée de type nombre complexe peut être classée
+ par sa valeur absolue, ou par sa partie entière.
+ Cela peut s'obtenir en définissant deux classes d'opérateurs pour ce
+ type de données et en sélectionnant la bonne classe à la création de l'index.
La classe d'opérateur détermine l'ordre de tri basique (qui peut ensuite
être modifié en ajoutant des options de tri comme
<literal>ASC</literal>/<literal>DESC</literal> et/ou
@@ -904,7 +907,7 @@
</para>
<para>
- Il y a quelques classes d'opérateurs en plus des classes par défaut:
+ Il y a quelques classes d'opérateurs en plus des classes par défaut :
<itemizedlist>
<listitem>
@@ -913,28 +916,29 @@
<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 par défaut est que
+ les types <type>text</type>, <type>varchar</type>, <type>char</type>,
+ et <type>name</type>, respectivement.
+ À la différence des classes d'opérateurs par défaut,
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) quand le serveur n'utilise pas la localisation standard
<quote>C</quote>.
- Par exemple, on pourrait indexer une colonne <type>varchar</type>
- comme ceci:
+ Par exemple, on peut indexer une colonne <type>varchar</type>
+ comme ceci :
<programlisting>CREATE INDEX test_index ON test_table (col varchar_pattern_ops);</programlisting>
- Notez 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
+ Il faut créer un index avec la classe d'opérateurs par
+ défaut pour 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.
- Si vous utilisez la locale C, vous n'avez pas besoin des classes
+ Si la locale C est utilisée, les classes
d'opérateur <literal><replaceable>xxx</replaceable>_pattern_ops</literal>
- car un index avec une classe d'opérateur par défaut est utilisable pour
+ ne sont pas nécessaires, car un index avec une classe d'opérateurs
+ par défaut est utilisable pour
les requêtes de correspondance de modèles dans la locale C.
</para>
</listitem>
@@ -942,7 +946,7 @@
</para>
<para>
- Les requêtes suivantes montrent toutes les classes d'opérateurs prédéfinies:
+ Les requêtes suivantes montrent les classes d'opérateurs prédéfinies :
<programlisting>SELECT am.amname AS index_method,
opc.opcname AS opclass_name
@@ -953,18 +957,18 @@
</para>
<para>
- Une classe d'opérateur est seulement un sous-ensemble d'une structure plus
- large appelée <firstterm>famille d'opérateur</firstterm>. Dans les cas où
- plusieurs types de données ont des comportements similaires, il est utile
- fréquemment de définir des opérateurs identiques pour plusieurs types de
+ Une classe d'opérateurs n'est qu'un sous-ensemble d'une structure plus
+ large appelée <firstterm>famille d'opérateurs</firstterm>. Dans les cas où
+ plusieurs types de données ont des comportements similaires, il est
+ fréquemment utile de définir des opérateurs identiques pour plusieurs types de
données et d'autoriser leur utilisation avec des index. Pour cela, les
classes d'opérateur de chacun de ces types doivent être groupés dans la
même famille d'opérateurs. Les opérateurs inter-types sont membres de la
- famille mas ne sont pas associés avec une seule classe de la famille.
+ famille, mais ne sont pas associés avec une seule classe de la famille.
</para>
<para>
- Cette requête affiche toutes les familles d'opérateur définies et tous les
+ Cette requête affiche toutes les familles d'opérateurs définies et tous les
opérateurs inclus dans chaque famille :
<programlisting>
SELECT am.amname AS index_method,
@@ -989,7 +993,7 @@
<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
+ de maintenance et 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"/>.
@@ -1002,9 +1006,9 @@
<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é
+ les index à créer. 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.
+ Une bonne dose d'expérimentation est nécessaire dans de nombreux cas.
Le reste de cette section donne quelques pistes.
</para>
@@ -1015,39 +1019,39 @@
<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
+ deviner le nombre de 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.
+ sans avoir lancé <command>ANALYZE</command> au préalable est, de ce fait,
+ peine 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,
+ Utiliser des données réelles pour l'expérimentation. Utiliser des
+ données de test pour mettre en place des index permet
+ de trouver les index utiles pour les données de test,
mais c'est tout.
</para>
<para>
Il est particulièrement néfaste d'utiliser des jeux de données
très réduits.
- Alors qu'une requête sélectionnant 1000 lignes parmi 100000 pourrait
+ Alors qu'une requête sélectionnant 1000 lignes parmi 100000 peut
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
+ dans une table de 100 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
+ Être vigilant en créant des données de test. C'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
+ Des valeurs très similaires, complètement aléatoires, ou
insérées déjà triées peuvent modifier la distribution des données et
fausser les statistiques.
</para>
@@ -1062,11 +1066,11 @@
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.
+ basiques, on force 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
une raison plus fondamentale qui empêche l'utilisation de l'index ;
- par exemple que la condition ne correspond pas à l'index.
+ la condition peut, par exemple, ne pas correspondre à l'index.
(Les sections précédentes expliquent quelles sortes de requêtes peuvent
utiliser quelles sortes d'index.)
</para>
@@ -1075,7 +1079,7 @@
<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
+ 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
@@ -1094,16 +1098,16 @@
des paramètres d'exécution (décrits dans la <xref
linkend="runtime-config-query-constants"/>).
Une estimation de sélectivité inadaptée est due à des statistiques
- insuffisantes. Il est peut être possible de les améliorer en
+ insuffisantes. Il 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
+ Si les coûts ne peuvent être ajustés à une meilleure représentation de la
+ réalité, alors il faut peut-être forcer l'utilisation de l'index
explicitement.
- Si vous le voulez, Vous pouvez aussi contacter les développeurs de
+ Il peut aussi s'avérer utile de contacter les développeurs de
<productname>PostgreSQL</productname> afin qu'ils examinent le problème.
</para>
</listitem>
More information about the Trad
mailing list