Skip to content

Commit

Permalink
Translate perform.xml
Browse files Browse the repository at this point in the history
  • Loading branch information
@rjuju @gleu
rjuju authored and gleu committed Jun 19, 2017
1 parent 7317ad4 commit f018012
Showing 1 changed file with 139 additions and 123 deletions.
262 changes: 139 additions & 123 deletions postgresql/perform.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1095,113 +1095,122 @@ WHERE tablename = 'road';
</sect2>

<sect2 id="planner-stats-extended">
<title>Extended Statistics</title>
<title>Statistiques étendues</title>

<indexterm zone="planner-stats-extended">
<primary>statistics</primary>
<secondary>of the planner</secondary>
<primary>statistiques</primary>
<secondary>de l'optimiseur</secondary>
</indexterm>

<indexterm>
<primary>correlation</primary>
<secondary>in the query planner</secondary>
<primary>corrélation</primary>
<secondary>dans l'optimiseur de requêtes</secondary>
</indexterm>

<indexterm>
<primary>pg_statistic_ext</primary>
</indexterm>

<para>
It is common to see slow queries running bad execution plans because
multiple columns used in the query clauses are correlated.
The planner normally assumes that multiple conditions
are independent of each other,
an assumption that does not hold when column values are correlated.
Regular statistics, because of their per-individual-column nature,
cannot capture any knowledge about cross-column correlation.
However, <productname>PostgreSQL</productname> has the ability to compute
<firstterm>multivariate statistics</firstterm>, which can capture
such information.
Il est habituel de voire des requêtes lentes tourner avec de mauvais plans
d'exécution car plusieurs colonnes utilisées dans les clauses de la requête
sont corrélées. L'optimiseur part normalement du principe que toutes les
conditions sont indépendantes les unes des autres, ce qui est faux quand
les valeurs des colonnes sont corrélées. Les statistiques classiques, du
fait qu'il s'agit par nature de statistique sur une seule colonne, ne
peuvent pas capturer d'information sur la corrélation entre colonnes.
Toutefois, <productname>PostgreSQL</productname> à la possibilité de
calculer des <firstterm>statistiques multivariées</firstterm>, qui peuvent
capturer une telle information.
</para>

<para>
Because the number of possible column combinations is very large,
it's impractical to compute multivariate statistics automatically.
Instead, <firstterm>extended statistics objects</firstterm>, more often
called just <firstterm>statistics objects</firstterm>, can be created to instruct
the server to obtain statistics across interesting sets of columns.
Comme le nombre de combinaisons de colonnes est très important, il n'est
pas possible de calculer les statistiques multivariées automatiquement. À
la place, des <firstterm>objets statistiques étendus</firstterm>, plus
souvent appelés simplement <firstterm>objets statistiques</firstterm>,
peuvent être crée pour faire savoir au serveur qu'il faut obtenir des
statistiques sur un ensemble intéressant de colonnes.
</para>

<para>
Statistics objects are created using
<xref linkend="sql-createstatistics"/>, which see for more details.
Creation of such an object merely creates a catalog entry expressing
interest in the statistics. Actual data collection is performed
by <command>ANALYZE</command> (either a manual command, or background
auto-analyze). The collected values can be examined in the
<link linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>
catalog.
Les objets statistiques sont crées en utilisant <xref
linkend="sql-createstatistics"/>, que vous pouvez consulter pour plus
de détails. La création de tels objets crée seulement un entrée dans le
catalogue pour exprimer l'intérêt dans cette statistique. La vraie
récupération de données est effectuée par <command>ANALYZE</command> (soit
une commande manuelle, soit une analyse automatique en tâche de fond). Les
valeurs colletées peuvent être examinées dans le catalogue <link
linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>.
</para>

<para>
<command>ANALYZE</command> computes extended statistics based on the same
sample of table rows that it takes for computing regular single-column
statistics. Since the sample size is increased by increasing the
statistics target for the table or any of its columns (as described in
the previous section), a larger statistics target will normally result in
more accurate extended statistics, as well as more time spent calculating
them.
<command>ANALYZE</command> calcule des statistiques étendues basées sur le
même ensemble de lignes de la table qu'il utilise pour calculer les
statistiques standard sur une seule colonne. Puisque la taille
d'échantillon peut être augmentée en augmentant la cible de statistique de
la table ou de n'importe laquelle de ses colonnes (comme c'est décrit dans
la section précédente), une plus grande cible de statistique donnera
normalement des statistiques étendues plus précises, mais nécessitera
également plus de temps pour les calculer.
</para>

<para>
The following subsections describe the types of extended statistics
that are currently supported.
La section suivante décrit les types de statistiques étendues qui sont
actuellement supportées.
</para>

<sect3>
<title>Functional Dependencies</title>
<title>Dépendances fonctionnelles</title>

<para>
The simplest type of extended statistics tracks <firstterm>functional
dependencies</firstterm>, a concept used in definitions of database normal forms.
We say that column <structfield>b</structfield> is functionally dependent on
column <structfield>a</structfield> if knowledge of the value of
<structfield>a</structfield> is sufficient to determine the value
of <structfield>b</structfield>, that is there are no two rows having the same value
of <structfield>a</structfield> but different values of <structfield>b</structfield>.
In a fully normalized database, functional dependencies should exist
only on primary keys and superkeys. However, in practice many data sets
are not fully normalized for various reasons; intentional
denormalization for performance reasons is a common example.
Even in a fully normalized database, there may be partial correlation
between some columns, which can be expressed as partial functional
dependency.
Le type le plus simple de statistiques étendues trace les
<firstterm>dépendances fonctionnelles </firstterm>, un concept utilisé
dans les définitions des formes normales des bases de données. On dit qu'une colonne
<structfield>b</structfield> est fonctionnellement dépendante d'une
colonne <structfield>a</structfield> si la connaissance de la valeur de
<structfield>a</structfield> est suffisante pour déterminer la valleur de
<structfield>b</structfield>, et donc qu'il n'existe pas deux lignes ayant
la même valeur de <structfield>a</structfield> mais avec des valeurs
différentes de <structfield>b</structfield>. Dans une base de données
complètement normalisée, les dépendances fonctionnelles ne devraient
exister que sur la clé primaire et les superclés. Toutefois, dans la
pratique beaucoup d'ensembles de données ne sont pas totalement normalisés
pour de nombreuses raisons; une dénormalisation intentionnelle pour des
raisons de performances est un exemple courant. Même dans une base de
données totalement normalisée, il peut y avoir une corrélation partielle
entre des colonnes, qui peuvent être exprimées comme une dépendance
fonctionnelle partielle.
</para>

<para>
The existence of functional dependencies directly affects the accuracy
of estimates in certain queries. If a query contains conditions on
both the independent and the dependent column(s), the
conditions on the dependent columns do not further reduce the result
size; but without knowledge of the functional dependency, the query
planner will assume that the conditions are independent, resulting
in underestimating the result size.
L'existence de dépendances fonctionnelles a un impact direct sur la
précision de l'estimation pour certaines requêtes. Si une requête
contient des contions à la fois sur des colonnes indépendantes et sur des
colonnes dépendantes, les conditions sur les colonnes dépendantes ne
résuident plus la taille du résultat; mais sans la connaissance de cette
dépendance fonctionnelle, l'optimiseur de requêtes supposera que les
conditions sont indépendantes, avec pour résultat une taille de résultat
sous estmiée.
</para>

<para>
To inform the planner about functional dependencies, <command>ANALYZE</command>
can collect measurements of cross-column dependency. Assessing the
degree of dependency between all sets of columns would be prohibitively
expensive, so data collection is limited to those groups of columns
appearing together in a statistics object defined with
the <literal>dependencies</literal> option. It is advisable to create
<literal>dependencies</literal> statistics only for column groups that are
strongly correlated, to avoid unnecessary overhead in both
<command>ANALYZE</command> and later query planning.
Pour informer l'optimiseur des dépendances fonctionnelles,
<command>ANALYZE</command> peut collecter des mesures sur des dépendances
entre des colonnes. Évaluer le degré de dépendance entre tous les
ensembles de colonnes aurait un coût prohibitif, c'est pourquoi la
collecte de données est limitée aux groupes de colonnes apparaissant
ensemble dans un objet statistiques défini avec l'option
<literal>dependencies</literal>. Il est conseillé de ne créer des
<literal>dépendences</literal> statistiques que pour les groupes de
colonnes qui sont fortement corrélés, pour éviter un surcout à la fois
dans <command>ANALYZE</command> et plus tard lors de la planification de
requête.
</para>

<para>
Here is an example of collecting functional-dependency statistics:
Voici un exemple de collecte de statistiques fonctionnellement dépendantes
:
<programlisting>
CREATE STATISTICS stts (dependencies) ON zip, city FROM zipcodes;

Expand All @@ -1215,83 +1224,88 @@ SELECT stxname, stxkeys, stxdependencies
stts | 1 5 | {"1 => 5": 1.000000, "5 => 1": 0.423130}
(1 row)
</programlisting>
Here it can be seen that column 1 (zip code) fully determines column
5 (city) so the coefficient is 1.0, while city only determines zip code
about 42% of the time, meaning that there are many cities (58%) that are
represented by more than a single ZIP code.
On peut voir ici que la colonne 1 (zip code) détermine complètement la
colonne 5 (city) et que donc le coefficient est 1.0, alors que la ville ne
détermine le code postal qu'environ 42% du temps, ce qui veut dire qu'il y
a beaucoup de villes (58%) qui sont représentées par plus d'un seul code
postal.
</para>

<para>
When computing the selectivity for a query involving functionally
dependent columns, the planner adjusts the per-condition selectivity
estimates using the dependency coefficients so as not to produce
an underestimate.
Lors du calcul de la sélectivité d'une requête impliquant des colonnes
fonctionnellement dépendantes, le planificateur ajoute l'estimation de
sélectivité par condition en utilisant les coefficients de dépendance afin
de ne pas produire de résultats sous estimé.
</para>

<sect4>
<title>Limitations of Functional Dependencies</title>
<title>Limites des Dépendances Fonctionnelles</title>

<para>
Functional dependencies are currently only applied when considering
simple equality conditions that compare columns to constant values.
They are not used to improve estimates for equality conditions
comparing two columns or comparing a column to an expression, nor for
range clauses, <literal>LIKE</literal> or any other type of condition.
Les dépendances fonctionnelles sont pour le moment uniquement appliquée
pour les conditions sur une simple égalité entre une colonne et une
valeur constante. Elles ne sont pas utilisées pour améliorer
l'estimation sur les conditions d'égalité entre deux colonnes ou la
comparaison d'une colonne avec une expression, ni pour les clauses
d'intervalle, <literal>LIKE</literal> ou tout autre type de condition.
</para>

<para>
When estimating with functional dependencies, the planner assumes that
conditions on the involved columns are compatible and hence redundant.
If they are incompatible, the correct estimate would be zero rows, but
that possibility is not considered. For example, given a query like
Lors d'une estimation avec des dépendances fonctionnelles, l'optimiseur
part du principe que les conditions sur les colonnes impliquées sont
compatibles et donc redondantes. Si elles sont incompatibles,
l'estimation correcte devrait être zéro ligne, mais cette possibilité
n'est pas envisagée. Par exemple, une requête telle que
<programlisting>
SELECT * FROM zipcodes WHERE city = 'San Francisco' AND zip = '94105';
</programlisting>
the planner will disregard the <structfield>city</structfield> clause as not
changing the selectivity, which is correct. However, it will make
the same assumption about
l'optimiseur négligera la clause <structfield>city</structfield>
puisqu'elle ne changera pas la sélectivité, ce qui est correct. Par
contre, il fera la même supposition pour
<programlisting>
SELECT * FROM zipcodes WHERE city = 'San Francisco' AND zip = '90210';
</programlisting>
even though there will really be zero rows satisfying this query.
Functional dependency statistics do not provide enough information
to conclude that, however.
bien qu'il n'y aura en réalité aucune ligne satisfaisant cette requête.
Toutefois, les statistiques de dépendances fonctionnelles ne fournissent
pas suffisamment d'information pour arriver à cette conclusion.
</para>

<para>
In many practical situations, this assumption is usually satisfied;
for example, there might be a GUI in the application that only allows
selecting compatible city and zipcode values to use in a query.
But if that's not the case, functional dependencies may not be a viable
option.
Pour beaucoup de situations pratiques, cette supposition est généralement
correcte; par exemple, il pourrait y avoir une GUI dans l'application qui
n'autorise que la sélection de villes et code postaux compatibles pour
l'utilisation dans une requête. Mais si ce n'est pas le cas, les
dépendances fonctionnelles pourraient ne pas être une solution viable.
</para>
</sect4>
</sect3>

<sect3>
<title>Multivariate N-Distinct Counts</title>
<title>Nombre N-Distinct multivarié</title>

<para>
Single-column statistics store the number of distinct values in each
column. Estimates of the number of distinct values when combining more
than one column (for example, for <literal>GROUP BY a, b</literal>) are
frequently wrong when the planner only has single-column statistical
data, causing it to select bad plans.
Les statistiques sur une seule colonne stockent le nombre de valeurs
distinctes pour chaque colonne. Les estimations du nombre de valeurs
distinctes combinant plus d'une colonne (par exemple, pour
<literal>GROUP BY a, b</literal>) sont souvent fausses quand l'optimiseur
ne dispose que de données statistiques par colonne, avec pour conséquence
le choix de mauvais plans.
</para>

<para>
To improve such estimates, <command>ANALYZE</command> can collect n-distinct
statistics for groups of columns. As before, it's impractical to do
this for every possible column grouping, so data is collected only for
those groups of columns appearing together in a statistics object
defined with the <literal>ndistinct</literal> option. Data will be collected
for each possible combination of two or more columns from the set of
listed columns.
Afin d'améliorer de telles estimations, <command>ANALYZE</command> peut
collecter des statistiques n-distinct pour des groupes de colonne. Comme
précédemment, ce n'est pas envisageable de le faire pour toutes les
regroupements de colonnes possibles, ainsi les données ne sont collectées
que pour les groupes de colonnes apparaissant ensemble dans un objet
statistiques défini avec l'option <literal>ndistinct</literal>. Des
données seront collectées pour chaque combinaison possible de deux
colonnes ou plus dans l'ensemble de colonnes listées.
</para>

<para>
Continuing the previous example, the n-distinct counts in a
table of ZIP codes might look like the following:
En continuant avec l'exemple précédent, le nombre n-distinct dans une
table de code postaux pourrait ressember à ceci :
<programlisting>
CREATE STATISTICS stts2 (ndistinct) ON zip, state, city FROM zipcodes;

Expand All @@ -1305,19 +1319,21 @@ k | 1 2 5
nd | {"1, 2": 33178, "1, 5": 33178, "2, 5": 27435, "1, 2, 5": 33178}
(1 row)
</programlisting>
This indicates that there are three combinations of columns that
have 33178 distinct values: ZIP code and state; ZIP code and city;
and ZIP code, city and state (the fact that they are all equal is
expected given that ZIP code alone is unique in this table). On the
other hand, the combination of city and state has only 27435 distinct
values.
Cela indique qu'il y a trois combinaisons de colonnes qui ont 33178
valeurs distincte : le code postale et l'état; le code postale et la
ville; et le code postal, la ville et l'état (le fait qu'ils soient tous
égaux est attendu puisque que le code postal seul est unique dans cette
table). D'un autre côté, la combinaison de la ville et de l'état n'a que
27435 valeurs distinctes.
</para>

<para>
It's advisable to create <literal>ndistinct</literal> statistics objects only
on combinations of columns that are actually used for grouping, and
for which misestimation of the number of groups is resulting in bad
plans. Otherwise, the <command>ANALYZE</command> cycles are just wasted.
Il est conseillé de créer des objets statistiques
<literal>ndistinct</literal> uniquement sur les combinaisons de colonnes
qui sont réellement utilisées pour des regroupement, et pour lesquelles
les mauvaises estimations du nombre de groupe a pour conséquence de
mauvais plants. Sinon, le temps passé par <command>ANALYZE</command> est
uniquement gâché.
</para>
</sect3>
</sect2>
Expand Down

0 comments on commit f018012

Please sign in to comment.