[Trad] [svn:pgfr] r1422 - traduc/trunk/postgresql
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Lun 23 Nov 10:22:57 CET 2009
Author: sas
Date: 2009-11-23 10:22:57 +0100 (Mon, 23 Nov 2009)
New Revision: 1422
Modified:
traduc/trunk/postgresql/acronyms.xml
traduc/trunk/postgresql/adminpack.xml
traduc/trunk/postgresql/advanced.xml
traduc/trunk/postgresql/array.xml
traduc/trunk/postgresql/auto-explain.xml
Log:
Petite relecture
Modified: traduc/trunk/postgresql/acronyms.xml
===================================================================
--- traduc/trunk/postgresql/acronyms.xml 2009-11-21 22:56:55 UTC (rev 1421)
+++ traduc/trunk/postgresql/acronyms.xml 2009-11-23 09:22:57 UTC (rev 1422)
@@ -398,7 +398,7 @@
<para>
<ulink
url="http://fr.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol">Lightweight
- Directory Access Protocol</ulink>, protocol léger d'accès aux annuaires
+ Directory Access Protocol</ulink>, protocole léger d'accès aux annuaires
</para>
</listitem>
</varlistentry>
@@ -460,7 +460,7 @@
<listitem>
<para>
<ulink url="http://fr.wikipedia.org/wiki/Olap">Online Analytical
- Processing</ulink>, triatement analytique en ligne
+ Processing</ulink>, traitement analytique en ligne
</para>
</listitem>
</varlistentry>
Modified: traduc/trunk/postgresql/adminpack.xml
===================================================================
--- traduc/trunk/postgresql/adminpack.xml 2009-11-21 22:56:55 UTC (rev 1421)
+++ traduc/trunk/postgresql/adminpack.xml 2009-11-23 09:22:57 UTC (rev 1422)
@@ -12,8 +12,8 @@
</indexterm>
<para>
- <filename>adminpack</filename> fournit un certain nombre de fonctions de
- support que <application>pgAdmin</application> ou autres outils de gestion
+ L'<filename>adminpack</filename> fournit un certain nombre de fonctions de
+ support que <application>pgAdmin</application> ou d'autres outils de gestion
et d'administration peuvent utiliser pour fournir des fonctionnalités
supplémentaires, comme la gestion à distance de journaux applicatifs.
</para>
Modified: traduc/trunk/postgresql/advanced.xml
===================================================================
--- traduc/trunk/postgresql/advanced.xml 2009-11-21 22:56:55 UTC (rev 1421)
+++ traduc/trunk/postgresql/advanced.xml 2009-11-23 09:22:57 UTC (rev 1422)
@@ -12,7 +12,7 @@
<title>Introduction</title>
<para>
- Le chapitre précédant couvre les bases de l'utilisation
+ Le chapitre précédent couvre les bases de l'utilisation
de <acronym>SQL</acronym> pour le stockage et l'accès aux données avec
<productname>PostgreSQL</productname>. Il est temps d'aborder
quelques fonctionnalités avancées du <acronym>SQL</acronym>
@@ -308,7 +308,7 @@
<para>
Le retour à un point de retournement ne l'annule pas. Il reste défini et
peut donc être utilisé plusieurs fois. À l'inverse, lorsqu'il n'est plus
- nécessaire de revenir à un point de sauvegarde pariculier, il peut être
+ nécessaire de revenir à un point de sauvegarde particulier, il peut être
relâché, ce qui permet de libérer des ressources systèmes. Il faut
savoir toutefois que relâcher un point de retournement, ou y revenir
relâche tous les points de sauvegarde qui ont été définis après.
@@ -360,20 +360,24 @@
<primary>fonction window</primary>
</indexterm>
+<!-- SAS:20091109
+ window function : fonction de fenêtrage ? -->
<para>
Une <firstterm>fonction window</firstterm> effectue un calcul sur un jeu
d'enregistrements liés d'une certaine façon à
l'enregistrement courant. On peut les rapprocher des calculs réalisables par
une fonction d'aggrégation mais, contrairement à une fonction d'aggrégation,
- l'utilisation d'une fonction window n'entraîne pas le regroupement des
+ l'utilisation d'une fonction <foreignphrase>window</foreignphrase> n'entraîne
+ pas le regroupement des
enregistrements traités en un seul — chaque enregistrement
- garde son identité propre. En coulisse, la fonction window est capable
+ garde son identité propre. En coulisse, la fonction
+ <foreignphrase>window</foreignphrase> est capable
d'accéder à d'autres enregistrements que l'enregistrement courant du résultat
de la requête.
</para>
<para>
- Voici un exemple qui montre comment comparer le salaire d'un employé avec
+ Comment comparer le salaire d'un employé avec
le salaire moyen de sa division :
<programlisting>
@@ -403,32 +407,33 @@
<structfield>nomdep</structfield> que la ligne courante. (Il s'agit
effectivement de la même fonction que la fonction d'aggrégat classique
<function>avg</function>, mais la clause <literal>OVER</literal> entraîne
- son exécution en tant que fonction window et son calcul sur le jeu
- approprié d'enregistrements.)
+ son exécution en tant que fonction <foreignphrase>window</foreignphrase> et
+ son calcul sur le jeu approprié d'enregistrements.)
</para>
<para>
- Un appel à une fonction window contient toujours une clause
+ Un appel à une fonction <foreignphrase>window</foreignphrase> contient toujours une clause
<literal>OVER</literal> qui suit le nom et les arguments de la fonction.
C'est ce qui permet de la distinguer syntaxiquement d'une fonction simple
ou d'une fonction de regroupement. La clause <literal>OVER</literal>
détermine précisément comment les lignes de la requête sont éclatées pour
- être traitées par la fonction window. La liste
+ être traitées par la fonction <foreignphrase>window</foreignphrase>. La liste
<literal>PARTITION BY</literal> contenue dans la clause
<literal>OVER</literal> spécifie comment répartir les enregistrements en
groupes, ou partitions, qui partagent les mêmes valeurs pour la (les)
expression(s) contenue(s) dans <literal>PARTITION BY</literal>. Pour chaque
- enregistrement, la fonction window est calculée sur les enregistrements
- qui se retrouvent dans la même partition que l'enregistrement courant.
+ enregistrement, la fonction <foreignphrase>window</foreignphrase> est calculée
+ sur les enregistrements qui se retrouvent dans la même partition que l'enregistrement courant.
</para>
<para>
Bien que la fonction <function>avg</function> produise le même résultat
quel que soit l'ordre dans lequel elle traite les enregistrements de la
- partition, ceci n'est pas généralisable à toutes les fonctions à fenêtre.
- Quand cela sera nécessaire, vous pourrez contrôler cet ordre en utilisant
- une clause <literal>ORDER BY</literal> à l'intérieur de
- <literal>OVER</literal>. En voici un exemple :
+ partition, ceci n'est pas généralisable à toutes les fonctions
+ <foreignphrase>window</foreignphrase>.
+ Lorsque cela s'avère nécessaire, l'ordre peut être contrôlé à l'aide d'une
+ clause <literal>ORDER BY</literal> à l'intérieur de
+ <literal>OVER</literal>. Exemple :
<programlisting>
SELECT nomdep, noemp, salaire, rank() OVER (PARTITION BY nomdep ORDER BY salaire DESC) FROM salaireemp;
@@ -450,7 +455,7 @@
(10 rows)
</screen>
- Comme vous avez pu le constater, la fonction <function>rank</function>
+ On remarque que la fonction <function>rank</function>
produit un rang numérique dans la partition de l'enregistrement pour chaque
valeur différente de l'<literal>ORDER BY</literal>, dans l'ordre défini
par la clause <literal>ORDER BY</literal>. <function>rank</function> n'a pas
@@ -459,30 +464,35 @@
</para>
<para>
- Les lignes prises en compte par une fonction window sont celles de la
+ Les lignes prises en compte par une fonction
+ <foreignphrase>window</foreignphrase> sont celles de la
<quote>table virtuelle</quote> produite par la clause <literal>FROM</literal>
de la requête filtrée par ses clauses <literal>WHERE</literal>,
<literal>GROUP BY</literal> et <literal>HAVING</literal>, s'il y en a.
Par exemple, une ligne rejetée parce qu'elle ne satisfait pas à la condition
- <literal>WHERE</literal> n'est vue par aucune fonction window.
- Une requête peut contenir plusieurs de ces fonctions window qui découpent
+ <literal>WHERE</literal> n'est vue par aucune fonction
+ <foreignphrase>window</foreignphrase>.
+ Une requête peut contenir plusieurs de ces fonctions
+ <foreignphrase>window</foreignphrase> qui découpent
les données de façons différentes, par le biais de clauses
<literal>OVER</literal> différentes, mais elles travaillent toutes sur le
même jeu d'enregistrements, défini par cette table virtuelle.
</para>
<para>
- Nous avons déjà vu que <literal>ORDER BY</literal> pouvait être omis si
+ <literal>ORDER BY</literal> peut être omis lorsque
l'ordre des enregistrements est sans importance. Il est aussi possible
d'omettre <literal>PARTITION BY</literal>, auquel cas il n'y a qu'une
partition, contenant tous les enregistrements.
</para>
<para>
- Il y a un autre concept important associé aux fonctions window :
+ Il y a un autre concept important associé aux fonctions
+ <foreignphrase>window</foreignphrase> :
pour chaque enregistrement, il existe un jeu d'enregistrements dans sa partition
appelé son <firstterm>window frame</firstterm> (cadre de fenêtre).
- Beaucoup (mais pas toutes) des fonctions window travaillent uniquement sur les
+ Beaucoup (mais pas toutes) de fonctions
+ <foreignphrase>window</foreignphrase> travaillent uniquement sur les
enregistrements du <foreignphrase>window frame</foreignphrase>, plutôt que
sur l'ensemble de la partition.
Par défaut, si on a précisé une clause <literal>ORDER BY</literal>, la
@@ -497,11 +507,11 @@
<para>
Il existe des options pour définir la <foreignphrase>window
frame</foreignphrase> autrement, mais ce
- tutorial ne les présente pas. Voyez
+ tutorial ne les présente pas. Voir
<xref linkend="syntax-window-functions"/> pour les détails.
</para>
</footnote>
- Voici un exemple utilisant <function>sum</function> :
+ Exemple utilisant <function>sum</function> :
</para>
<programlisting>
@@ -525,7 +535,7 @@
</screen>
<para>
- Ci-dessus, puisqu'il n'y a pas d'<literal>ORDER BY</literal> dans la clause
+ Dans l'exemple Ci-dessus, puisqu'il n'y a pas d'<literal>ORDER BY</literal> dans la clause
<literal>OVER</literal>, la <foreignphrase>window frame</foreignphrase> est
égale à la partition ; en d'autres
termes, chaque somme est calculée sur toute la table, ce qui fait qu'on a le
@@ -564,17 +574,19 @@
<literal>SELECT</literal> et la clause <literal>ORDER BY</literal> de la
requête. Elles sont interdites ailleurs, comme par exemple dans les clauses
<literal>GROUP BY</literal>,<literal>HAVING</literal> et
- <literal>WHERE</literal>. La raison est qu'elles sont exécutées après le
- traitement de ces clauses. Par ailleurs, les fonctions window s'exécutent
+ <literal>WHERE</literal>. La raison en est qu'elles sont exécutées après le
+ traitement de ces clauses. Par ailleurs, les fonctions
+ <foreignphrase>window</foreignphrase> s'exécutent
après les fonctions d'aggrégat classiques. Cela signifie qu'il est permis
- d'inclure une fonction d'aggrégat dans les arguments d'une fonction window,
+ d'inclure une fonction d'aggrégat dans les arguments d'une fonction
+ <foreignphrase>window</foreignphrase>,
mais pas l'inverse.
</para>
<para>
S'il y a besoin de filtrer ou de grouper les enregistrements
- après que le calcul des fonctions window ait été effectué, vous pouvez
- utiliser un sous-select. Par exemple :
+ après le calcul des fonctions <foreignphrase>window<foreignphrase>, un
+ sous-select peut être utilisé. Par exemple :
<programlisting>
SELECT nomdep, noemp, salaire, date_embauche
@@ -591,12 +603,14 @@
</para>
<para>
- Quand une requête met en jeu plusieurs fonctions window, il est possible
+ Quand une requête met en jeu plusieurs fonctions
+ <foreignphrase>window</foreignphrase>, il est possible
d'écrire chacune avec une clause <literal>OVER</literal> différente,
- mais cela entraine des duplications de code et augmente les risques d'erreurs
- si on souhaite le même comportement pour plusieurs fonctions window. À la place,
- chaque comportement window peut être associé à un nom dans une clause
- <literal>WINDOW</literal> et ensuite référence dans <literal>OVER</literal>.
+ mais cela entraîne des duplications de code et augmente les risques d'erreurs
+ si on souhaite le même comportement pour plusieurs fonctions
+ <foreignphrase>window</foreignphrase>. À la place,
+ chaque comportement <foreignphrase>window</foreignphrase> peut être associé à un nom dans une clause
+ <literal>WINDOW</literal> et ensuite être référencé dans <literal>OVER</literal>.
Par exemple :
<programlisting>
@@ -660,7 +674,7 @@
</para>
<para>
- Une meilleure solution peut-être :
+ Une meilleure solution peut être :
<programlisting>CREATE TABLE villes (
nom text,
Modified: traduc/trunk/postgresql/array.xml
===================================================================
--- traduc/trunk/postgresql/array.xml 2009-11-21 22:56:55 UTC (rev 1421)
+++ traduc/trunk/postgresql/array.xml 2009-11-23 09:22:57 UTC (rev 1422)
@@ -128,7 +128,7 @@
</para>
<para>
- Ces types de constantes de tableau sont en fait un cas particulier
+ Ces types de constantes tableau sont en fait un cas particulier
des constantes de type générique abordées dans la <xref
linkend="sql-syntax-constants-generic"/>. La constante est traitée
initialement comme une chaîne et passée à la routine de conversion d'entrées
@@ -643,9 +643,9 @@
guillemets doubles, antislashs ou espace (en début comme en fin) doivent
avoir des guillemets doubles. Les chaînes vides et les chaînes <literal>NULL</literal>
doivent aussi être entre guillemets. Pour placer un guillemet double ou un antislash
- dans une valeur d'élément d'un tableau, utilisez la syntaxe d'échappement des
- chaînes et faites-la le précèder d'un antislash.
- Comme alternative, vous pouvez vous passer de guillemets et utiliser l'échappement par
+ dans une valeur d'élément d'un tableau, on utilise la syntaxe d'échappement des
+ chaînes en le précédant d'un antislash.
+ Alternativement, il est possible de se passer de guillemets et d'utiliser l'échappement par
antislash pour protéger tous les caractères de données qui seraient autrement interprétés
en tant que caractères de syntaxe de tableau.
</para>
Modified: traduc/trunk/postgresql/auto-explain.xml
===================================================================
--- traduc/trunk/postgresql/auto-explain.xml 2009-11-21 22:56:55 UTC (rev 1421)
+++ traduc/trunk/postgresql/auto-explain.xml 2009-11-23 09:22:57 UTC (rev 1422)
@@ -5,167 +5,167 @@
révision $Revision: 1300 $ -->
<sect1 id="auto-explain">
- <title>auto_explain</title>
+ <title>auto_explain</title>
+
+ <indexterm zone="auto-explain">
+ <primary>auto_explain</primary>
+ </indexterm>
+
+ <para>
+ Le module <filename>auto_explain</filename> fournit un moyen de tracer les
+ plans d'exécution des requêtes lentes automatiquement, sans qu'il soit
+ nécessaire de lancer
+ <xref linkend="sql-explain" endterm="sql-explain-title"/>
+ manuellement. C'est particulièrement utile pour repérer les requêtes
+ non optimisées sur de grosses applications.
+ </para>
+
+ <para>
+ Le module ne fournit pas de fonctions accessibles par SQL.
+ Pour l'utiliser, il suffit de le charger sur le serveur.
+ Il peut être chargé dans une session individuelle :
+
+ <programlisting>
+ LOAD 'auto_explain';
+ </programlisting>
+
+ (Seul le super-utilisateur peut le faire.)
+ Un usage plus caractéristique est de le précharger dans toutes les sessions
+ en incluant <literal>auto_explain</literal> dans
+ <xref linkend="guc-shared-preload-libraries"/> dans le fichier
+ <filename>postgresql.conf</filename>. Il est alors possible de récupérer les requêtes
+ lentes non prévues, quel que soit le moment où elles se produisent. Évidemment, il y a un prix
+ à payer pour cela.
+ </para>
- <indexterm zone="auto-explain">
- <primary>auto_explain</primary>
- </indexterm>
+<sect2>
+ <title>Paramètres de configuration</title>
+
+ <para>
+ Plusieurs paramètres de configuration contrôlent le comportement
+ d'<filename>auto_explain</filename>. Le comportement par défaut est
+ de ne rien faire. Il est donc nécessaire de préciser au minimum
+ <varname>auto_explain.log_min_duration</varname> pour obtenir un résultat.
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term>
+ <varname>auto_explain.log_min_duration</varname> (<type>integer</type>)
+ </term>
+ <indexterm>
+ <primary>paramètre de configuration <varname>auto_explain.log_min_duration</varname></primary>
+ </indexterm>
+ <listitem>
+ <para>
+ <varname>auto_explain.log_min_duration</varname> est la durée minimale
+ d'exécution de requête à partir de laquelle le plan d'exécution
+ sera tracé. Son unité est la milliseconde. La positionner à zéro trace
+ tous les plans. -1 (la valeur par défaut) désactive l'écriture des plans.
+ Positionnée à <literal>250ms</literal>,
+ tous les ordres qui durent 250 ms ou plus seront tracés. Seuls les
+ super-utilisateurs peuvent modifier ce paramétrage.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <varname>auto_explain.log_analyze</varname> (<type>boolean</type>)
+ </term>
+ <indexterm>
+ <primary>paramètre de configuration <varname>auto_explain.log_analyze</varname></primary>
+ </indexterm>
+ <listitem>
+ <para>
+ <varname>auto_explain.log_analyze</varname> entraîne
+ l'écriture du résultat de <command>EXPLAIN ANALYZE</command>,
+ à la place du résultat de <command>EXPLAIN</command>,
+ lorsqu'un plan d'exécution est tracé.
+ Ce paramètre est désactivé par défaut.
+ Seuls les super-utilisateurs peuvent modifier ce paramètre.
+ </para>
+ <note>
+ <para>
+ Lorsque ce paramètre est activé, un chronométrage par
+ nœud du plan est calculé pour
+ tous les ordres exécutés, qu'ils durent suffisamment longtemps pour être réellement tracés, ou non.
+ Ceci peut avoir des conséquences très négatives sur les performances.
+ </para>
+ </note>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <varname>auto_explain.log_verbose</varname> (<type>boolean</type>)
+ </term>
+ <indexterm>
+ <primary>paramètre de configuration <varname>auto_explain.log_verbose</varname></primary>
+ </indexterm>
+ <listitem>
+ <para>
+ <varname>auto_explain.log_verbose</varname> entraîne l'écriture
+ du résultat de <command>EXPLAIN VERBOSE</command>
+ au lieu du résultat de la commande simple <command>EXPLAIN</command>,
+ lorsqu'un plan d'exécution est tracé. Ce paramètre est désactivé par défaut.
+ Seuls les super-utilisateurs peuvent modifier ce paramètre.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <varname>auto_explain.log_nested_statements</varname> (<type>boolean</type>)
+ </term>
+ <indexterm>
+ <primary>paramètre de configuration <varname>auto_explain.log_nested_statements</varname></primary>
+ </indexterm>
+ <listitem>
+ <para>
+ <varname>auto_explain.log_nested_statements</varname> entraîne
+ la prise en compte des ordres imbriqués
+ (les requêtes exécutées dans une fonction) dans la trace.
+ Quand il est désactivé, seuls les plans d'exécution
+ de plus haut niveau sont tracés. Ce paramètre est désactivé par
+ défaut. Seuls les super-utilisateurs peuvent modifier ce paramètre.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>
+ Pour positionner ces paramètres dans le fichier
+ <filename>postgresql.conf</filename>,
+ il convient d'ajouter <literal>auto_explain</literal> à
+ <xref linkend="guc-custom-variable-classes"/>. Un usage classique serait :
+ </para>
+
+ <programlisting>
+ # postgresql.conf
+ shared_preload_libraries = 'auto_explain'
+
+ custom_variable_classes = 'auto_explain'
+ auto_explain.log_min_duration = '3s'
+ </programlisting>
+</sect2>
- <para>
- Le module <filename>auto_explain</filename> fournit un moyen de tracer les
- plans d'exécution des requêtes lentes automatiquement, sans devoir lancer
- <xref linkend="sql-explain" endterm="sql-explain-title"/>
- manuellement. C'est particulièrement utile pour repérer les requêtes
- non optimisées sur de grosses applications.
- </para>
+<sect2>
+ <title>Exemple</title>
- <para>
- Le module ne fournit pas de fonctions accessibles par SQL.
- Pour l'utiliser, chargez-le simplement sur le serveur.
- Vous pouvez le charger dans une session individuelle :
-
- <programlisting>
- LOAD 'auto_explain';
- </programlisting>
-
- (Vous devez être le super-utilisateur pour faire cela.)
- Un usage plus caractéristique est de le précharger dans toutes les sessions
- en incluant <literal>auto_explain</literal> dans
- <xref linkend="guc-shared-preload-libraries"/> dans le fichier
- <filename>postgresql.conf</filename>. Ensuite vous pouvez pister les requêtes
- étonnament lentes, quel que soit le moment où cela se produit. Évidemment, il y a un prix
- à payer pour cela.
- </para>
+ <programlisting>
+ postgres=# LOAD 'auto_explain';
+ postgres=# SET auto_explain.log_min_duration = 0;
+ postgres=# SELECT count(*)
+ FROM pg_class, pg_index
+ WHERE oid = indrelid AND indisunique;
+ </programlisting>
- <sect2>
- <title>Paramètres de configuration</title>
-
- <para>
- Il y a plusieurs paramètres de configuration qui contrôlent le comportement
- d'<filename>auto_explain</filename>. Notez que le comportement par défaut est
- de ne rien faire. Vous devez donc préciser au moins
- <varname>auto_explain.log_min_duration</varname> si vous voulez un résultat.
- </para>
-
- <variablelist>
- <varlistentry>
- <term>
- <varname>auto_explain.log_min_duration</varname> (<type>integer</type>)
- </term>
- <indexterm>
- <primary>paramètre de configuration <varname>auto_explain.log_min_duration</varname></primary>
- </indexterm>
- <listitem>
- <para>
- <varname>auto_explain.log_min_duration</varname> est la durée minimale
- d'exécution de requête à partir de laquelle le plan d'exécution
- sera tracé. Son unité est la millisecondes. Le positionner à zéro trace
- tous les plans. -1 (la valeur par défaut) désactive l'écriture des plans. Par
- exemple, si vous le positionnez à <literal>250ms</literal>, alors
- tous les ordres qui durent 250 ms ou plus seront tracés. Seuls les
- super-utilisateurs peuvent modifier ce paramétrage.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <varname>auto_explain.log_analyze</varname> (<type>boolean</type>)
- </term>
- <indexterm>
- <primary>paramètre de configuration <varname>auto_explain.log_analyze</varname></primary>
- </indexterm>
- <listitem>
- <para>
- <varname>auto_explain.log_analyze</varname> entraîne
- l'écriture du résultat de <command>EXPLAIN ANALYZE</command>,
- à la place du résultat de <command>EXPLAIN</command>,
- lorsqu'un plan d'exécution est tracé.
- Ce paramètre est désactivé par défaut.
- Seuls les super-utilisateurs peuvent modifier ce paramètre.
- </para>
- <note>
- <para>
- Lorsque ce paramètre est activé, un chronométrage par
- nœud du plan est calculé pour
- tous les ordres exécutés, qu'ils durent suffisamment longtemps pour être réellement tracés, ou non.
- Ceci peut avoir des conséquences très négatives sur les performances.
- </para>
- </note>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <varname>auto_explain.log_verbose</varname> (<type>boolean</type>)
- </term>
- <indexterm>
- <primary>paramètre de configuration <varname>auto_explain.log_verbose</varname></primary>
- </indexterm>
- <listitem>
- <para>
- <varname>auto_explain.log_verbose</varname> entraîne l'écriture
- du résultat de <command>EXPLAIN VERBOSE</command>
- au lieu du résultat de la commande simple <command>EXPLAIN</command>
- lorsqu'un plan d'exécution
- est tracé. Ce paramètre est désactivé par défaut. Seuls les
- superutilisateurs peuvent modifier ce paramètre.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <varname>auto_explain.log_nested_statements</varname> (<type>boolean</type>)
- </term>
- <indexterm>
- <primary>paramètre de configuration <varname>auto_explain.log_nested_statements</varname></primary>
- </indexterm>
- <listitem>
- <para>
- <varname>auto_explain.log_nested_statements</varname> entraîne
- la prise en compte des ordres imbriqués
- (les requêtes exécutées dans une fonction) dans la trace.
- Quand il est désactivé, seuls les plans d'exécution
- de plus haut niveau sont tracés. Ce paramètre est désactivé par
- défaut. Seuls les super-utilisateurs peuvent modifier ce paramètre.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>
- Afin de positionner ces paramètres dans votre fichier
- <filename>postgresql.conf</filename>,
- vous devez ajouter <literal>auto_explain</literal> à
- <xref linkend="guc-custom-variable-classes"/>. Un usage classique serait :
- </para>
-
- <programlisting>
- # postgresql.conf
- shared_preload_libraries = 'auto_explain'
-
- custom_variable_classes = 'auto_explain'
- auto_explain.log_min_duration = '3s'
- </programlisting>
- </sect2>
+ <para>
+ Ceci devrait produire un résultat de ce style dans les journaux applicatifs :
+ </para>
- <sect2>
- <title>Exemple</title>
-
- <programlisting>
- postgres=# LOAD 'auto_explain';
- postgres=# SET auto_explain.log_min_duration = 0;
- postgres=# SELECT count(*)
- FROM pg_class, pg_index
- WHERE oid = indrelid AND indisunique;
- </programlisting>
-
- <para>
- Ceci devrait produire un résultat de ce style dans les journaux applicatifs :
- </para>
-
- <programlisting><![CDATA[ LOG: duration: 0.986 ms plan:
+ <programlisting><![CDATA[ LOG: duration: 0.986 ms plan:
Aggregate (cost=14.90..14.91 rows=1 width=0)
-> Hash Join (cost=3.91..14.70 rows=81 width=0)
Hash Cond: (pg_class.oid = pg_index.indrelid)
@@ -176,15 +176,15 @@
STATEMENT: SELECT count(*)
FROM pg_class, pg_index
WHERE oid = indrelid AND indisunique;]]>
- </programlisting>
- </sect2>
+ </programlisting>
+</sect2>
- <sect2>
- <title>Auteur</title>
+<sect2>
+ <title>Auteur</title>
- <para>
- Takahiro Itagaki <email>itagaki.takahiro at oss.ntt.co.jp</email>
- </para>
- </sect2>
+ <para>
+ Takahiro Itagaki <email>itagaki.takahiro at oss.ntt.co.jp</email>
+ </para>
+</sect2>
</sect1>
Plus d'informations sur la liste de diffusion Trad