[Trad] [svn:pgfr] r1209 - traduc/trunk/postgresql
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Mer 10 Déc 00:52:46 CET 2008
Author: sas
Date: 2008-12-10 00:52:46 +0100 (Wed, 10 Dec 2008)
New Revision: 1209
Modified:
traduc/trunk/postgresql/indices.xml
Log:
Relecture en cours
Modified: traduc/trunk/postgresql/indices.xml
===================================================================
--- traduc/trunk/postgresql/indices.xml 2008-12-08 11:21:28 UTC (rev 1208)
+++ traduc/trunk/postgresql/indices.xml 2008-12-09 23:52:46 UTC (rev 1209)
@@ -385,29 +385,29 @@
correspondantes dans un ordre imprécis, dépendant de l'implantation.
</para>
-<!-- SAS::ICI -->
<para>
- 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
- de la table, le tri explicite a des chances d'être plus rapide car il
- nécessite moins d'entrées/sorties disque grâce à un modèle d'accès mieux
- ordonné. Les index sont plus utiles quand seules quelques lignes doivent
- être récupérées. Un cas spécial important est le <literal>ORDER BY</literal>
- en combinaison avec <literal>LIMIT</literal> <replaceable>n</replaceable> :
- un tri explicite devra traiter toutes les données pour identifier les
+ Le planificateur répond à une clause <literal>ORDER BY</literal>
+ soit en parcourant un 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 de parcourir une fraction importante
+ de la table, le tri explicite est probablement plus rapide car il
+ nécessite moins d'entrées/sorties disque, du fait d'un modèle d'accès mieux
+ ordonné. Les index sont plus utiles lorsqu'il s'agit de ne récupérer que
+ quelques lignes être récupérées. <literal>ORDER BY</literal>
+ combiné à <literal>LIMIT</literal> <replaceable>n</replaceable> est un cas
+ spécial très important :
+ un tri explicite doit traiter toutes les données pour identifier les
<replaceable>n</replaceable> première lignes, mais s'il y a un index
- correspondant au <literal>ORDER BY</literal>, alors les
- <replaceable>n</replaceable> lignes peuvent être récupérées directement
- sans avoir besoin de parcourir le reste.
+ qui correspond à l'<literal>ORDER BY</literal>, alors les
+ <replaceable>n</replaceable> premières lignes peuvent être récupérées directement
+ sans qu'il soit nécessaires de parcourir les autres.
</para>
<para>
- Par défaut, les index B-tree stockent leurs entrées dans l'ordre ascendant
- avec les valeurs NULL en dernier. Cela signifie qu'un parcours en avant
- d'un index sur une colonne <literal>x</literal> produira une sortie
- satisfaisant un <literal>ORDER BY x</literal> (ou en plus verbeux
+ Par défaut, les index B-tree stockent leurs entrées dans l'ordre ascendant,
+ valeurs NULL en dernier. Cela signifie que le parcours avant
+ d'un index sur une colonne <literal>x</literal> produit une sortie
+ satisfaisant <literal>ORDER BY x</literal> (ou en plus verbeux
<literal>ORDER BY x ASC NULLS LAST</literal>). L'index peut aussi être
parcouru en arrière, produisant ainsi une sortie satisfaisant un
<literal>ORDER BY x DESC</literal> (ou en plus verbeux
@@ -417,7 +417,7 @@
</para>
<para>
- Vous pouvez ajuster l'ordre d'un index B-tree en incluant les options
+ L'ordre d'un index B-tree peut être défini à la création par l'inclusion des options
<literal>ASC</literal>, <literal>DESC</literal>, <literal>NULLS FIRST</literal>,
et/ou <literal>NULLS LAST</literal> lors de la création de l'index ; par
exemple :
@@ -427,31 +427,33 @@
</programlisting>
Un index stocké en ordre ascendant avec les valeurs NULL en premier peut
satisfaire soit <literal>ORDER BY x ASC NULLS FIRST</literal> soit
- <literal>ORDER BY x DESC NULLS LAST</literal> suivant la direction du
+ <literal>ORDER BY x DESC NULLS LAST</literal> selon la direction du
parcours.
</para>
<para>
- Vous vous demandez l'intérêt des quatre options quand deux options ensemble
- avec la possibilité d'un parcours en sens inverse couvrirait toutes les
- variantes d'<literal>ORDER BY</literal>. Dans les index sur une colonne,
- les options sont en fait redondantes mais dans un index à plusieurs colonnes,
- elles sont utiles. Pensez à un index à deux colonnes
- <literal>(x, y)</literal> : il peut satisfaire une clause <literal>ORDER
- BY x, y</literal> si nous parcourons en avant, ou
- <literal>ORDER BY x DESC, y DESC</literal> dans un parcours inverse.
+ On peut s'interroger sur l'intérêt de proposer quatre options, alors que
+ deux options associées à la possibilité d'un parcours inverse semblent
+ suffire à couvrir toutes les
+ variantes d'<literal>ORDER BY</literal>. Dans les index mono-colonne,
+ les options sont en effet redondantes, mais pour un index à plusieurs colonnes,
+ elles sont utiles. Si l'on considère un index à deux colonnes
+ <literal>(x, y)</literal>, il peut satisfaire une clause <literal>ORDER
+ BY x, y</literal> sur un parcours avant, ou
+ <literal>ORDER BY x DESC, y DESC</literal> sur un parcours inverse.
Mais il se peut que l'application utilise fréquemment
<literal>ORDER BY x ASC, y DESC</literal>. Il n'y a pas moyen d'obtenir cet
ordre à partir d'un index standard, mais c'est possible si l'index est défini
- ainsi : <literal>(x ASC, y DESC)</literal> or <literal>(x DESC, y
+ comme <literal>(x ASC, y DESC)</literal> or <literal>(x DESC, y
ASC)</literal>.
</para>
<para>
- Évidemment, les index avec un ordre autre que celui par défaut sont une
- fonctionnalité très spécialisée. Quelque fois, elles peuvent apporter des
- performances conséquentes pour certaines requêtes. Leur intérêt dépend
- surtout de la fréquence des requêtes nécessitant cet ordre spécial.
+ Les index d'ordre différent de celui par défaut sont visiblement une
+ fonctionnalité très spécialisée, mais ils peuvent parfois être à l'origine
+ d'accélérations spectaculaires des performances sur certaines requêtes.
+ L'intérêt de maintenir un tel index dépend
+ de la fréquence des requêtes qui nécessitent un tri particulier.
</para>
</sect1>
@@ -469,48 +471,48 @@
</indexterm>
<para>
- Un parcours d'index simple utilise les clauses de la requête qui utilisent
+ Un parcours unique d'index ne peut utiliser que les clauses de la requête qui utilisent
les colonnes de l'index avec les opérateurs de sa classe d'opérateur et qui
- sont joint avec <literal>AND</literal>. Par exemple, étant donné un index sur
+ sont jointes avec <literal>AND</literal>. Par exemple, étant donné un index sur
<literal>(a, b)</literal>, une condition de requête <literal>WHERE a = 5
- AND b = 6</literal> pourrait utiliser l'index mais une requête comme
- <literal>WHERE a = 5 OR b = 6</literal> ne pourrait pas utiliser directement
- l'index.
+ AND b = 6</literal> peut utiliser l'index, mais une requête
+ <literal>WHERE a = 5 OR b = 6</literal> ne peutt pas l'utiliser directement.
</para>
<para>
- À partir de la version 8.1, <productname>PostgreSQL</productname> peut combiner
+ Depuis la version 8.1, <productname>PostgreSQL</productname> peut combiner
plusieurs index (y compris plusieurs utilisations du même index) pour gérer
- les cas qui ne peuvent pas être implémentés avec des parcours d'index
+ les cas qui ne peuvent pas être résolus par des parcours d'index
simples. Le système peut former des conditions <literal>AND</literal>
- et <literal>OR</literal> au travers de plusieurs parcours d'index. Par exemple,
+ et <literal>OR</literal> sur plusieurs parcours d'index. Par exemple,
une requête comme <literal>WHERE x = 42 OR x = 47 OR x = 53 OR x = 99</literal>
- pourrait être divisée en quatre parcours séparés d'un index sur
+ peut être divisée en quatre parcours distincts d'un index sur
<literal>x</literal>, chaque parcours utilisant une des clauses de la requête. Les
- résultats de ces parcours sont alors assemblés avec un OR pour produire le
- résultat. Un autre exemple est que, si nous avons des index séparés sur
- <literal>x</literal> et <literal>y</literal>, une implémentation possible d'une requête
- comme <literal>WHERE x = 5 AND y = 6</literal> est d'utiliser chaque index avec la
+ résultats de ces parcours sont alors assemblés par OR pour produire le
+ résultat. Autre exemple, s'il existe des index séparés sur
+ <literal>x</literal> et <literal>y</literal>, une résolution possible d'une requête
+ comme <literal>WHERE x = 5 AND y = 6</literal> consiste à utiliser chaque index avec la
clause de la requête appropriée et d'assembler les différents résultats
avec un AND pour identifier les lignes résultantes.
</para>
<para>
Pour combiner plusieurs index, le système parcourt chaque index nécessaire
- et prépare un <firstterm>bitmap</firstterm> en mémoire en donnant l'emplacement des
- lignes de table qui sont rapportées comme correspondant aux conditions de
+ et prépare un <firstterm>bitmap</firstterm> en mémoire qui donne l'emplacement des
+ lignes de table qui correspondent aux conditions de
l'index. Les bitmaps sont ensuite assemblés avec des opérateurs AND ou OR
- suivant les besoins de la requête. Enfin, les lignes réelles de la table
+ selon les besoins de la requête. Enfin, les lignes réelles de la table
sont visitées et renvoyées. Elles sont visitées dans l'ordre physique parce
- c'est ainsi que le bitmap est créé ; cela signifie que tout ordre
- des index originaux est perdu et que, du coup, une étape de tri séparée sera
+ c'est ainsi que le bitmap est créé ; cela signifie que l'ordre
+ des index originaux est perdu et que, du coup, une étape de tri séparée est
nécessaire si la requête comprend une clause <literal>ORDER BY</literal>. Pour
cette raison, et parce que chaque parcours d'index supplémentaire ajoute
- un temps additionnel, le planificateur choisira quelque fois d'utiliser un
+ un temps additionnel, le planificateur choisit quelque fois d'utiliser un
parcours d'index simple même si des index supplémentaires sont disponibles
- et auraient aussi pû être utilisés.
+ 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
More information about the Trad
mailing list