root/traduc/branches/bv747/divers/annotated_postgresql_conf.xml

<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- SAS 20060728 : Traduction initiale -->
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" >

<article id="postgresqlconf" lang="fr">
 <articleinfo>
  <title>Fichier postgresql.conf et guide de configuration utilisateur générale
  (<foreignphrase>Global User Configuration [GUC]</foreignphrase>) annotés</title>
  <subtitle>PostgreSQL 7.4.x</subtitle>
</articleinfo>

<sect1>
<title>Connexions et authentification</title>

<sect2>
<title>Paramètres de connexion</title>

<table>
<tgroup cols="8" align="left" colsep="1" rowsep="1">

<thead>
 <row>
  <entry>Paramètre</entry>
  <entry>Échelle</entry>
  <entry>Ressources</entry>
  <entry>Valeur par défaut</entry>
  <entry>Positionnement</entry>
  <entry>-o</entry>
  <entry>Ce que dit la documentation</entry>
  <entry>Commentaires</entry>
 </row>
</thead>

<tbody>
 <row>
  <entry>tcpip_socket</entry>
  <entry>true, false</entry>
  <entry>Aucune</entry>
  <entry>false</entry>
  <entry>non</entry>
  <entry>-i</entry>
  <entry>
  Positionné à true, le serveur accepte les connexions TCP/IP. Dans le cas
  contraire, seules les connexions par la socket de domaine Unix sont
  autorisées.
  </entry>
  <entry>
  Sauf dans le cas d'un serveur de test, ce paramètre doit probablement être
  positionné à true. Il est recommandé de faire cela
  <emphasis>après</emphasis> avoir configuré le fichier pg_hba.conf, pour
  sécuriser les accès.
  </entry>
 </row>
 <row>
  <entry>max_connections</entry>
  <entry>2 à Int Max</entry>
  <entry>14ko RAM</entry>
  <entry>32</entry>
  <entry>Non</entry>
  <entry>-N #</entry>
  <entry>
  Nombre maximum de connexions concurrentes à un serveur de bases de données.
  La valeur par défaut est 32 (à moins qu'elle n'ait été modifiée lors de
  la construction du serveur).
  </entry>
  <entry>
  Paramètre important. &Agrave; conserver le plus bas possible pour la
  configuration de l'application. En combinaison avec une application web
  à connexions persistantes, il doit être possible de l'abaisser vers 10-16.
  </entry>
 </row>
 <row>
  <entry>superuser_reserved_connections</entry>
  <entry>0 à max_connections - 1</entry>
  <entry>Réduit le nombre de connexions standard disponibles</entry>
  <entry>2</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Nombre de connexions réservées aux superutilisateurs PostgreSQL. Au plus
  max_connections connexions peuvent être actives simultanément. Lorsque
  le nombre de connexions concurrentes atteint max_connections moins
  superuser_reserved_connections, seules les connexions de superutilisateurs
  sont encore autorisées.
  </entry>
  <entry>
  Cela protège l'accès des superutilisateurs en cas d'engorgement de la base.
  Ce paramètre ne doit être positionné à 0 que lorsqu'il est certain que
  toutes les connexions ne sont jamais utilisées. (NDR&nbsp;: je positionne
  souvent ce paramètre à 1 puisque je ne me connecte à la base en superutilisateur
  qu'en cas de problème.) 
  </entry>
 </row>
 <row>
  <entry>port</entry>
  <entry>129 à 32768</entry>
  <entry>Aucune</entry>
  <entry>5432</entry>
  <entry>Non</entry>
  <entry>-p #</entry>
  <entry>
  Le port TCP sur lequel le serveur écoute.
  </entry>
  <entry>
  <para>
  Le changement du port PostgreSQL peut être une protection contre les vers
  de bases et les <emphasis>script kiddies</emphasis>. Néanmoins, il ne faudra pas oublier
  de donner l'option de port à <emphasis>tous</emphasis> les logiciels et
  bibliothèques effectuant une connexion, ce qui peut s'avérer pénible.
  </para>
  </entry>
 </row>
 <row>
  <entry>unix_socket_directory</entry>
  <entry></entry>
  <entry></entry>
  <entry>''</entry>
  <entry>Non</entry>
  <entry>-k $</entry>
  <entry>
  Répertoire du socket de domaine Unix sur lequel le serveur écoute
  les connexions de clients. Par défaut, c'est /tmp, mais le paramètre
  peut être modifié à la compilation.
  </entry>
  <entry>
  Ces options s'appliquent aux connexions UDP vers le serveur, utilisées en
  général uniquement à partir d'une console sur le serveur. (NDR&nbsp;:
  Comme je considère les connexions UDP non sécurisées, je les désactive.
  Je n'ai donc pas de recommendation particulière.)
  </entry>
 </row>
 <row>
  <entry>unix_socket_group</entry>
  <entry></entry>
  <entry></entry>
  <entry>''</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Groupe propriétaire du socket de domaine Unix (l'utilisateur propriétaire
  de ce socket est toujours celui qui exécute le serveur). Combiné avec l'option
  UNIX_SOCKET_PERMISSIONS, ce paramètre peut être utilisé comme mécanisme
  supplémentaire de contrôle des accès pour ce type de socket. Par défaut, 
  c'est une chaîne vide, donc le groupe par défaut de l'utilisateur.
  </entry>
 </row>
 <row>
  <entry>unix_socket_permissions</entry>
  <entry></entry>
  <entry></entry>
  <entry>0777</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  <para>Droits d'accès au socket de domaine Unix. Les sockets de domaine
  Unix utilisent le système habituel de gestion des droits des systèmes de
  fichiers Unix. La valeur de l'option doit être précisée sous la forme
  numérique acceptée par les outils système chmod et umask. L'utilisation du
  format octal impose un 0 (zéro) en début de nombre.
  </para>
  </entry>
 </row>
</tbody>
</tgroup>
</table>

</sect2>

<sect2>
<title>Sécurité et authentification</title>

<table>
<tgroup cols="8" align="left" colsep="1" rowsep="1">

<thead>
 <row>
  <entry>Paramètre</entry>
  <entry>&Eacute;chelle</entry>
  <entry>Ressources</entry>
  <entry>Valeur par défaut</entry>
  <entry>Positionnement</entry>
  <entry>-o</entry>
  <entry>Ce que dit la documentation</entry>
  <entry>Commentaires</entry>
 </row>
</thead>

<tbody>
 <row>
  <entry>authentication_timeout</entry>
  <entry>1-600 sec</entry>
  <entry></entry>
  <entry>60</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Temps maximum laissé à un client pour réussir l'authentification, en secondes.
  Si un client potentiel n'a pas terminé la séquence d'authentification
  pendant ce laps de temps, le serveur met fin à la connexion. Cela permet 
  d'éviter qu'un client bloqué n'occupe indéfiniment une connexion.
  Cette option, lue au démarrage, ne peut être positionnée qu'en ligne 
  de commande ou dans le fichier postgresql.conf.
  </entry>
  <entry>
  </entry>
 </row>
 <row>
  <entry>ssl</entry>
  <entry>true, false</entry>
  <entry>Voir les notes</entry>
  <entry>false</entry>
  <entry>Non</entry>
  <entry>-l</entry>
  <entry>Autoriser les connexions SSL</entry>
  <entry>
  SSL chiffre le traffic sur le port TCP/IP de sorte que les données
  transférées ne puissent pas être lues normalement. Du fait du chiffrement,
  cela implique une charge intense du CPU à la fois sur le client et le
  serveur. Cela peut aussi accroître la taille des données transférées.
  Néanmoins, SSL peut être difficile
  à configurer, et tous les clients ne supportent pas l'accès SSL.
  </entry>
 </row>
 <row>
  <entry>krb_server_keyfile</entry>
  <entry></entry>
  <entry></entry>
  <entry>''</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Positionne l'implantation du fichier de clés du serveur Kerberos.
  </entry>
  <entry>
  Utilisé uniquement pour l'authentification Kerberos des utilisateurs.
  </entry>
 </row>
 <row>
  <entry>virtual_host</entry>
  <entry></entry>
  <entry></entry>
  <entry>''</entry>
  <entry>Non</entry>
  <entry>-h x</entry>
  <entry>
  Positionne le nom d'hôte ou l'adresse TCP/IP sur lequel/laquelle le
  postmaster écoute les connexions des applications clientes. Par défaut,
  écoute sur toutes les adresses configurées (y compris localhost).
  </entry>
  <entry>
  Essentiel pour les bases sur un réseau sécurisé comprenant une DMZ, ou
  lorsque le serveur de bases de données possède une adresse TCP/IP publique
  et une privée.
  </entry>
 </row>
 <row>
  <entry>db_user_namespace</entry>
  <entry>true, false</entry>
  <entry></entry>
  <entry>false</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Permet les noms d'utilisateur par base de données. Désactivé par défaut.
  </entry>
  <entry>
  Par défaut, les utilisateurs peuvent se connecter à
  n'importe quelle base. Dans certains cas, ce scénario n'est pas acceptable.
  Dans de tels cas, il est possible d'utiliser cette option. Cette
  fonctionnalité s'entend comme une mesure intermédiaire en attendant une
  solution complète. Cette option sera supprimée par la suite.
  </entry>
 </row>
</tbody>
</tgroup>
</table>

</sect2>

</sect1>

<sect1>
<title>Utilisation des ressources</title>

<sect2>
<title>Mémoire</title>

<note>
 <para>
  L'augmentation de la plupart de ces paramètres impose de règler les options
  du noyau système à la valeur de la mémoire autorisée par processus ou par
  utilisateur. La documentation en ligne donne des <ulink url="http://docs.postgresqlfr.org/7.4/kernel-resources.html">informations sur les
  commandes en fonction des systèmes d'exploitation</ulink>. Sauf indication contraire,
  toutes les options mémoire s'additionnent pour déterminer la quantité totale
  de mémoire utilisée par PostgreSQL.
 </para>
</note>

<table>
<tgroup cols="8" align="left" colsep="1" rowsep="1">

<thead>
 <row>
  <entry>Paramètre</entry>
  <entry>&Eacute;chelle</entry>
  <entry>Ressources</entry>
  <entry>Valeur par défaut</entry>
  <entry>Positionnement</entry>
  <entry>-o</entry>
  <entry>Ce que dit la documentation</entry>
  <entry>Commentaires</entry>
 </row>
</thead>

<tbody>
 <row>
  <entry>shared_buffers</entry>
  <entry>16 à Int Max</entry>
  <entry>8K RAM</entry>
  <entry>64</entry>
  <entry>Non</entry>
  <entry>-B x</entry>
  <entry>
  Positionne le nombre de tampons de mémoire partagée utilisé par le 
  serveur de bases de données. Le minimum est 2 X max_connections.
  </entry>
  <entry>
  <para>
  Positionne la taille du tampon mémoire de PostgreSQL où les requêtes sont
  stockées avant d'être passées au tampon noyau du système. Ce n'est qu'une
  zone de stockage, et <emphasis>non</emphasis> le total de la taille
  mémoire disponible pour le serveur. De ce fait, il est fortement
  déconseillé de positionner ce nombre à une part importante de la RAM, cela
  ayant des conséquences désastreuses sur les performances avec beaucoup de
  systèmes d'exploitation. Les membres de la liste de diffusion
  pgsql-performance ont abouti à une échelle utile se situant entre 1000 et
  6000, fonction de la RAM, de la taille de la base de données et du nombre de
  requêtes concurrentes. Pour les serveurs qui disposent d'une grande quantité
  de RAM (supérieure à 1 Go), l'augmentation de ce paramètre vers 6 à 15% de
  la RAM disponible a donné de bons résultats dans la plupart des cas.
  L'analyse réelle du meilleur paramétrage n'est pas exactement comprise,
  et l'expérience plus que le calcul permet l'ajustement de ce paramètre.
  </para>
  <para>
  Une règle empirique consiste à observer l'utilisation de la mémoire partagée
  par PostgreSQL à l'aide d'outils tel ipcs pour déterminer la valeur du
  paramètre. Cela ne représente toutefois que la moitié du paramétrage.
  Il est également nécessaire de régler effective_cache_size pour que
  PostgreSQL puisse utiliser efficacement la mémoire disponible.
  </para>
  </entry>
 </row>
 <row>
  <entry>
  sort_mem
  </entry>
  <entry>64 à Int Max</entry>
  <entry>1 KB</entry>
  <entry>1024</entry>
  <entry>Oui</entry>
  <entry>-S #</entry>
  <entry>
  <para>
  Précise la quantité de mémoire utilisable par les opérations de tri interne et
  les tables de hachage avant d'utiliser des fichiers temporaires. La valeur
  est indiquée en kilooctets, la valeur par défaut est 1024 Ko (soit 1 Mo).
  En cas de requête complexe, de nombreuses opérations de tri ou de hachage
  peuvent s'exécuter en parallèle&nbsp;; chacune peut utiliser la quantité
  de mémoire indiquée par la valeur de ce paramètre avant de commencer à
  utiliser des fichiers temporaires. De plus, de nombreuses sessions
  peuvent effectuer ces opérations en parallèle. La mémoire totale
  utilisée peut être plusieurs fois la valeur de SORT_MEM. Les opérations
  de tri sont utilisées par ORDER BY, DISTINCT et les jointures.
  </para>
  <para>
  Les options en ligne de commande nécessitent d'utiliser -o 'option'.
  </para>
  </entry>
  <entry>
  <para>
  sort_mem est difficile à ajuster. Une plus grande valeur est utilisée
  pour&nbsp;: les
  bases de données volumineuses, les requêtes complexes, une grande quantité de 
  RAM disponible. Une plus petite valeur est recherchée pour&nbsp;: une faible
  quantité de RAM ou de nombreux accès concurrents. Trouver le bon compromis
  peut s'avérer délicat.
  </para>
  <para>
  Une autre façon d'ajuster cette valeur consiste à surveiller les fichiers
  temporaires de PostgreSQL (dans PGDATA/base/OID_BASE/pgsql_tmp) et d'accroître
  la valeur de sort_mem si de nombreuses requêtes permutent avec ces fichiers.
  </para>
  <para>
  Il ne faut pas oublier que ce paramètre peut être positionné par connexion.
  Ainsi, dans le cas où seules quelques requêtes très complexes sont à
  exécuter, la valeur peut être augmentée avant leur exécution, mais conservée
  basse pour les autres connexions.
  </para>
  </entry>
 </row>
 <row>
  <entry>vacuum_mem</entry>
  <entry>1024 à Int Max</entry>
  <entry>1 Ko</entry>
  <entry>8192</entry>
  <entry>Oui</entry>
  <entry></entry>
  <entry>
  Précise la quantité maximale de mémoire que VACUUM peut utiliser pour
  conserver une trace des lignes à ré-utiliser. La valeur est précisée en Ko.
  La valeur par défaut est de 8&nbsp;192&nbsp;ko. Une valeur supérieure peut
  accélérer le nettoyage de grandes tables dont de nombreuses lignes ont été
  supprimées.
  </entry>
  <entry>
  <para>
  Ce paramètre n'utilise de RAM que lors des VACUUM. Il peut donc être augmenté
  sur les machines disposant de beaucoup de RAM pour accéler les VACUUM (mais pas
  plus de 20% de la RAM disponible).
  </para>
  <para>
  Ce paramètre peut de plus être positionné à l'exécution. Il peut alors être
  judicieux de le régler à une valeur basse pour les VACUUM réguliers et de le
  positionner à une valeur plus élevée pour les VACUUM FULL de
  nuit/hebdomadaires/périodiques.
  </para>
  </entry>
 </row>
</tbody>
</tgroup>
</table>

</sect2>

<sect2>
<title>Free Space Map</title>

<table>
<tgroup cols="8" align="left" colsep="1" rowsep="1">

<thead>
 <row>
  <entry>Paramètre</entry>
  <entry>&Eacute;chelle</entry>
  <entry>Ressources</entry>
  <entry>Valeur par défaut</entry>
  <entry>Positionnement</entry>
  <entry>-o</entry>
  <entry>Ce que dit la documentation</entry>
  <entry>Commentaires</entry>
 </row>
</thead>

<tbody>
 <row>
  <entry>max_fsm_pages</entry>
  <entry>1000 à Int Max</entry>
  <entry>6 octets RAM</entry>
  <entry>10000</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Positionne le nombre maximum de pages disque pour lesquels l'espace
  libre est recherché dans la carte de l'espace libre partagé.
  La valeur par défaut est 10&nbsp;000. Cette option ne peut être positionnée 
  qu'au démarrage du serveur.
  </entry>
  <entry>
  <para>
  Un paramétrage correct de la FSM peut éliminer, ou au moins, retarder
  l'obligation d'exécuter VACUUM FULL et REINDEX. La meilleure façon de le
  régler est la suivante&nbsp;:
  <orderedlist>
    <itemizedlist><para>calculer la fréquence du VACUUM (normal) de la
  base en fonction des écritures&nbsp;;</para></itemizedlist>
    <itemizedlist><para>utiliser la base en fonctionnement
  normal et exécuter VACUUM VERBOSE ANALYZE à la place de VACUUM, en
  sauvegardant la sortie dans un fichier&nbsp;;</para></itemizedlist>
    <itemizedlist><para>calculer le nombre de pages maximum
  réclamé par VACUUM et utiliser ce chiffre.</para></itemizedlist>
  </orderedlist>
  </para>
  <para>
  Si l'approche précédente n'est pas réalisable, essayer d'estimer le nombre
  total de lignes qui peuvent être actualisées ou supprimées entre deux VACUUM, et
  utiliser la moitié de ce nombre, en l'augmentant en fonction de la quantité de
  travail qu'un VACUUM FULL périodique continue d'effectuer.
  </para>
  <para>
  Pour les base de données qui connaissent des &laquo;&nbsp;pics&nbsp;&raquo;
  d'activité (rafales d'un million de mises à jour mais pas d'autre
  activité des minutes ou des heures durant), ce nombre peut être 
  impossible à optimiser. Les lignes insérées n'ont pas d'impact
  sur la FSM. Enfin, si le serveur est peu fourni en RAM, augmenter
  cette valeur peut s'avérer contre-productif.
  </para>
  </entry>
 </row>
 <row>
  <entry>max_fsm_relations</entry>
  <entry>10 à Int Max</entry>
  <entry>40 octets RAM</entry>
  <entry>100</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Positionne le nombre maximum de relations (tables) pour
  lesquels l'espace libre est recherché dans la carte de l'espace libre
  partagé.
  </entry>
  <entry>
  Ce paramètre doit être positionné au nombre de tables attendues dans la
  base... entre 300 et 500. PostgreSQL a un comportement étrange s'il ne possède
  pas assez de FSM_relations.
  </entry>
 </row>
</tbody>
</tgroup>
</table>

</sect2>

<sect2>
<title>Utilisation des ressources disque</title>

<table>
<tgroup cols="8" align="left" colsep="1" rowsep="1">

<thead>
 <row>
  <entry>Paramètre</entry>
  <entry>&Eacute;chelle</entry>
  <entry>Ressources</entry>
  <entry>Valeur par défaut</entry>
  <entry>Positionnement</entry>
  <entry>-o</entry>
  <entry>Ce que dit la documentation</entry>
  <entry>Commentaires</entry>
 </row>
</thead>

<tbody>
 <row>
  <entry>max_files_per_process</entry>
  <entry>25 à Int Max</entry>
  <entry></entry>
  <entry>1000</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Fixe le nombre maximum de fichiers simultanément ouverts par chaque
  sous-processus du serveur. La valeur par défaut est 1&nbsp;000. 
  La limite actuellement utilisée par le code est la plus petite valeur du
  paramètre et le résultat de sysconf(_SC_OPEN_MAX). Toutefois, sur les systèmes
  pour lesquels sysconf retourne une valeur raisonnable, il n'est pas nécessaire
  de s'inquiéter de ce paramètre. Mais sur la plupart des plateformes
  (et notamment BSD), sysconf retourne une valeur
  beaucoup plus grande que ce que le système peut réellement prendre en charge
  lorsque de nombreux processus essayent tous d'ouvrir ce nombre de fichiers.
  Si le message d'erreur &laquo;&nbsp;Trop de fichiers ouverts&nbsp;&raquo;
  (<foreignphrase>"Too many open files"</foreignphrase>) apparaît, 
  il faut alors essayer de réduire ce paramètre. Il ne peut être
  fixé qu'au démarrage du serveur ou dans le fichier postgresql.conf. Modifié
  dans le fichier de configuration, il n'affectera que les sous-processus serveur
  ouverts après modification.
  </entry>
  <entry>
  D'après la documentation, utilisé essentiellement pour BSD. À considérer
  uniquement
  à l'appartion de messages &laquo;&nbsp;Trop de fichiers ouverts&nbsp;&raquo;
  (<foreignphrase>"Too many open files"</foreignphrase>).
  </entry>
 </row>
 <row>
  <entry>preload_libraries</entry>
  <entry>Chemin de fichier</entry>
  <entry>Voir les notes</entry>
  <entry>Vide</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Indique les bibliothèques à précharger au démarrage du serveur. Une
  fonction d'initialisation peut optionnellement être
  appelée pour chaque bibliothèque. Pour cela, il suffit d'ajouter un 
  double-point et le nom de la fonction d'initialisation après le
  nom de la bibliothèque. '$libdir/mylib:mylib_init' implique, par exemple,
  le préchargement de mylib et l'exécution de la fonction mylib_init.
  Si plusieurs bibliothèques doivent être chargées, leurs noms
  sont séparés par des virgules. Si mylib n'est pas trouvée, le serveur ne
  démarrera pas. En revanche, si init_mylib n'est pas trouvée, mylib est
  préchargée sans exécuter la fonction d'initialisation.  </entry>
  <entry>
  Le préchargement (et l'initialisation éventuelle) d'une bibliothèque
  partagée permet d'éviter le temps de chargement de la bibliothèque
  la première fois qu'elle est utilisée. Cela se traduit par un temps de
  démarrage du serveur plus long et des temps d'appel des bibliothèques qui ne
  sont pas chargées en mémoire plus courts.
  </entry>
 </row>
</tbody>
</tgroup>
</table>

</sect2>

</sect1>

<sect1>
<title>Options WAL</title>

<sect2>
<title>Paramètres</title>

<table>
<tgroup cols="8" align="left" colsep="1" rowsep="1">

<thead>
 <row>
  <entry>Paramètre</entry>
  <entry>&Eacute;chelle</entry>
  <entry>Ressources</entry>
  <entry>Valeur par défaut</entry>
  <entry>Positionnement</entry>
  <entry>-o</entry>
  <entry>Ce que dit la documentation</entry>
  <entry>Commentaires</entry>
 </row>
</thead>

<tbody>
 <row>
  <entry>fsync</entry>
  <entry>true, false</entry>
  <entry>Voir les notes</entry>
  <entry>true</entry>
  <entry>Non</entry>
  <entry>-F (off)</entry>
  <entry>
  Lorsque cette option est activée, le serveur PostgreSQL utilise les appels
  système fsync() pour s'assurer que les mises à jour sont physiquement écrites
  sur le disque. Cela garantit la récupération d'une bases de données
  cohérente après une panne matérielle ou système. Ce fonctionnement n'a aucune
  incidence sur la gestion des pannes du serveur de bases de données.
  </entry>
  <entry>
  <note>
  <para>
  Depuis la version 7.2, la désactivation de fsync n'arrête
  <emphasis>PAS</emphasis> le WAL. Toutefois, il n'y a plus de points de reprise.
  La journalisation des écritures anticipées (<foreignphrase>Write-Ahead
  Logging ou WAL</foreignphrase>) ne doit être désactivée (fsync=off) que sur
  les bases en
  lecture seule ou celles qu'il est possible de régénérer à l'aide de logiciels
  externes. Tandis que du RAID associé à un système de haute-disponibilité
  électrique peuvent aider à la protection des données, la désactivation de
  fsync <emphasis>impose</emphasis> la restauration des données à partir de
  sauvegardes en cas de pannes matériel ou électrique.
  </para>
  </note>
  <para>
  D'un autre côté, le WAL implique une baisse de performances lors des
  écritures, à
  plus forte raison sur des systèmes mono-disques. Pour l'essentiel l'activité
  nécessaire aux opérations de lecture/écriture est doublée à chaque mise à
  jour. De plus, les fonctionnalités d'amélioration des performances par cache
  disque matériel ou logiciel sont désactivées.
  </para>
  <para>
   Si le WAL est arrêté, les options qui suivent n'ont pas d'intérêt.
  </para>
  </entry>
 </row>
 <row>
  <entry>wal_sync_method</entry>
  <entry>fsync, fdatasync, open_sync ou open_datasync</entry>
  <entry></entry>
  <entry>Dépend de la plateforme</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Méthode utilisée pour forcer la mise à jour des WAL sur le disque. Les valeurs
  possibles sont FSYNC (fsync() est appelé à chaque validation), FDATASYNC
  (fdatasync() est appelé à chaque validation), OPEN_SYNC (écrit les fichiers
  WAL avec l'option O_SYNC d'open()) et OPEN_DATASYNC (écrit les fichiers WAL
  avec l'option O_DSYNC d'open()). Ces choix ne sont pas tous disponibles sur
  toutes les plateformes.
  </entry>
  <entry>
  Il s'agit de l'appel système utilisé pour synchroniser les WAL sur disque. La
  valeur par défaut a été réglée pour chaque OS en fonction de la documentation
  de l'OS. En revanche, aucun test comparatif n'a été mené. Il est possible que
  le changement de méthode accélère l'écriture sur une plateforme spécifique,
  mais cela ne doit être tenté que si les ressources nécessaires à des tests
  comparatifs et de régression sont disponibles. La modification des valeurs par
  défaut peut altérer la protection par le WAL.
  </entry>
 </row>
 <row>
  <entry>wal_buffers</entry>
  <entry>4 à Int Max</entry>
  <entry>8K RAM</entry>
  <entry>8</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Nombre de tampons de pages disque alloués dans la mémoire partagée
  pour la journalisation du WAL.
  </entry>
  <entry>
  L'accroissement de ce paramètre peut accélérer les écritures du WAL pour les
  transactions volumineuses. &Agrave; ce jour, personne n'a rendu compte d'une
  analyse de l'impact de ce paramètre.
  </entry>
 </row>
</tbody>
</tgroup>
</table>

</sect2>

<sect2>
<title>Checkpoints</title>

<table>
<tgroup cols="8" align="left" colsep="1" rowsep="1">

<thead>
 <row>
  <entry>Paramètre</entry>
  <entry>&Eacute;chelle</entry>
  <entry>Ressources</entry>
  <entry>Valeur par défaut</entry>
  <entry>Positionnement</entry>
  <entry>-o</entry>
  <entry>Ce que dit la documentation</entry>
  <entry>Commentaires</entry>
 </row>
</thead>

<tbody>
 <row>
  <entry>checkpoint_segments</entry>
  <entry>1 à Int Max</entry>
  <entry>16 Mo sur disque</entry>
  <entry>3</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Distance maximale entre deux points de contôle WAL automatiques, en segments
  de fichier journal (chaque segment représente normalement 16 Mo).
  </entry>
  <entry>
  Ce paramètre est augmenté lorsque la base requiert de nombreuses écritures
  d'arrière-plan pour diminuer la fréquence des points de reprise (et ainsi
  diminuer l'activité du disque). Si la place disque manque ou que l'environnement
  présente un risque de coupures de courant inattendues, ce paramètre peut être
  diminué. En effet, toute transaction non visée par un point de reprise sera
  supprimée au redémarrage.
  </entry>
 </row>
 <row>
  <entry>checkpoint_timeout</entry>
  <entry>30 à 3600</entry>
  <entry>Voir les notes</entry>
  <entry>300</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Temps maximal entre deux points de contôle WAL automatiques, en secondes.
  </entry>
  <entry></entry>
 </row>
 <row>
  <entry>checkpoint_warning</entry>
  <entry>0 à Int Max</entry>
  <entry>Voir les notes</entry>
  <entry>0</entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Un message est envoyé dans les journaux du serveur si la fréquence des points
  de contrôle
  engendrés par le remplissage des fichiers de segments de points de contrôle 
  est supérieure à ce temps, en secondes. Zéro désactive les alertes.
  </entry>
  <entry>
  Nouvelle option qui peut être utile pour affiner les checkpoint_segments sur
  les bases à forte activité d'écriture. Des alertes
  nombreuses dans les journaux incitent à accroitre le paramètre
  checkpoint_segments.
  </entry>
 </row>
 <row>
  <entry>commit_delay</entry>
  <entry>0-100000</entry>
  <entry>Voir les notes</entry>
  <entry>0</entry>
  <entry>Oui</entry>
  <entry></entry>
  <entry>
  Indique le délai, en microsecondes, entre l'écriture d'une validation dans le
  tampon WAL et la purge du tampon sur disque. Un délai positif peut permettre
  la validation de plusieurs transactions avec un seul appel système fsync(), si
  la charge système est suffisamment élevée pour que de nouvelles transactions
  soient prêtes pendant cet interval. Mais ce délai est perdu dans le cas
  contraire. Ainsi, le délai n'est exécuté que si au moins commit_siblings
  autres
  transactions sont actives au moment où le processus serveur a écrit sa
  validation.
  </entry>
  <entry>
  Ces deux paramètres sont configurés ensemble pour un environnement à fort
  volume de petites transactions. Activés, ils permettent de purger en même
  temps sur disques des transactions sans relation entre elles, qui autrement ne
  le seraient pas, avec à la clé un potentiel accroissement des performances.
  En revanche, si l'espace disque est restreint ou que la stabilité électrique
  de l'environnement ne peut être garantie, il est préférable de ne pas modifier
  ces paramètres.
  </entry>
 </row>
 <row>
  <entry>commit_siblings</entry>
  <entry>1-1000</entry>
  <entry>Voir les notes</entry>
  <entry>5</entry>
  <entry>Oui</entry>
  <entry></entry>
  <entry>
  Indique le nombre minimum de transactions concurrentes ouvertes avant
  l'éxécution du délai COMMIT_DELAY. Plus la valeur est grande, plus la
  probabilité de valider une autre transaction pendant cet interval grandit.
  </entry>
  <entry>
  </entry>
 </row>
</tbody>
</tgroup>
</table>

</sect2>

</sect1>

<sect1>
<title>Optimisation des requêtes</title>

<sect2>
<title>Méthodes du planificateur</title>

<table>
<tgroup cols="8" align="left" colsep="1" rowsep="1">

<thead>
 <row>
  <entry>Paramètre</entry>
  <entry>&Eacute;chelle</entry>
  <entry>Ressources</entry>
  <entry>Valeur par défaut</entry>
  <entry>Positionnement</entry>
  <entry>-o</entry>
  <entry>Ce que dit la documentation</entry>
  <entry>Commentaires</entry>
 </row>
</thead>

<tbody>
 <row>
  <entry>
  <para>enable_hashagg</para>
  <para>enable_hashjoin</para>
  <para>enable_indexscan</para>
  <para>enable_mergejoin</para>
  <para>enable_nestloop</para>
  <para>enable_seqscan</para>
  <para>enable_sort</para>
  <para>enable_tidscan</para>
  </entry>
  <entry>true, false</entry>
  <entry></entry>
  <entry>true</entry>
  <entry>Oui</entry>
  <entry>
  <para></para>
  <para>-fi</para>
  <para>-fm</para>
  <para>-fn</para>
  <para>-fs</para>
  <para></para>
  <para>-ft*</para>
  <para></para>
  </entry>
  <entry>
  <para>
  Active ou désactive l'utilisation des types de plan respectifs par le
  planificateur de requêtes.
  Activé par défaut, on les utilise pour déboguer le planificateur de requêtes.
  </para>
  <para>
  Les options en ligne de commande requièrent l'utilisation de -o 'option'.
  </para>
  </entry>
  <entry>
  <para>
  Ces options ne devraient être utilisées que pour tester les requêtes&nbsp;; il
  est courant, par exemple, de positionner
  &laquo;&nbsp;enable_seqscan&nbsp;=&nbsp;false&nbsp;&raquo;
  pour déterminer si le planificateur n'omet pas inutilement un index. Quoi
  qu'il en soit, seules des circonstances extraordinaires nécessitent qu'un
  de ces paramètres soit positionné à <foreignphrase>false</foreignphrase> dans
  le fichier .conf.
  </para>
  </entry>
 </row>
</tbody>
</tgroup>
</table>

</sect2>

<sect2>
<title>Constantes de coût du planificateur</title>

<table>
<tgroup cols="8" align="left" colsep="1" rowsep="1">

<thead>
 <row>
  <entry>Paramètre</entry>
  <entry>&Eacute;chelle</entry>
  <entry>Ressources</entry>
  <entry>Valeur par défaut</entry>
  <entry>Positionnement</entry>
  <entry>-o</entry>
  <entry>Ce que dit la documentation</entry>
  <entry>Commentaires</entry>
 </row>
</thead>

<tbody>
 <row>
  <entry>effective_cache_size</entry>
  <entry>0 à Int Max</entry>
  <entry>8 Ko</entry>
  <entry>1000</entry>
  <entry>Oui</entry>
  <entry></entry>
  <entry>
  Fournit à l'optimiseur une estimation de la taille efficace du cache
  disque (c'est-à-dire la partie du cache disque du noyau utilisée pour les
  fichiers de données PostgreSQL). Elle est mesurée en pages disque, chacune
  de 8 ko.
  </entry>
  <entry>
  Ce paramètre, bien que souvent négligé, peut, s'il est correctement réglé
  conduire à une meilleure utilisation de la RAM sur les ordinateurs disposant de
  beaucoup de mémoire. (NDR&nbsp;: j'utilise 25% de ma &laquo;&nbsp;RAM
  disponible&nbsp;&raquo; [après Linux et les applications] comme niveau général,
  mais n'ai pas testé plus avant). Si ce paramètre est optimisé, il n'est pas
  nécessaire d'augmenter inutilement shared_buffers.
  </entry>
 </row>
 <row>
  <entry>
  <para>random_page_cost</para>
  <para>cpu_tuple_cost</para>
  <para>cpu_index_tuple_cost</para>
  <para>cpu_operator_cost</para>
  </entry>
  <entry>0 à Double</entry>
  <entry>
  <para></para>
  <para>0.01</para>
  <para>0.001</para>
  <para>0.0025</para>
  </entry>
  <entry>4</entry>
  <entry>
  </entry>
  <entry>Oui</entry>
  <entry>
  Fournit au planificateur une estimation du coût de traitement de chaque
  consultation de page, tuple, consultation d'index et item de clause where
  (respectivement) lors d'une requête. Elle est mesurée en multiples du coût de
  récupération séquentielle d'une page.
  </entry>
  <entry>
  Les coûts par défaut sont fondés entièrement sur l'expérience et ne sont
  probablement pas optimaux pour tout système. Par exemple, les machines disposant
  de disques rapides peuvent abaisser le random_page_cost. Lorsque différentes
  valeurs sont testées pour ces paramètres, il est nécessaire de tester une grande
  variété de requêtes, car un bon paramétrage pour une requête peut ne pas
  s'appliquer à une autre. Heureusement, ces paramètres étant tous relatifs au
  coût d'un parcours séquentiel, le risque qu'ils soient trop élevés dans un
  système équilibré est assez faible.
  </entry>
 </row>
</tbody>
</tgroup>
</table>

</sect2>

<sect2>
<title>Optimisation génétique de requêtes (<foreignphrase>Genetic Estimate Query
Optimizer, GEQO</foreignphrase>)</title>

<table>
<tgroup cols="8" align="left" colsep="1" rowsep="1">

<thead>
 <row>
  <entry>Paramètre</entry>
  <entry>&Eacute;chelle</entry>
  <entry>Ressources</entry>
  <entry>Valeur par défaut</entry>
  <entry>Positionnement</entry>
  <entry>-o</entry>
  <entry>Ce que dit la documentation</entry>
  <entry>Commentaires</entry>
 </row>
</thead>

<tbody>
 <row>
  <entry>geqo</entry>
  <entry>true, false</entry>
  <entry></entry>
  <entry>true</entry>
  <entry></entry>
  <entry></entry>
  <entry>
  Active ou désactive l'optimisation génétique de requêtes. Il s'agit en fait
  d'un algorithme génétique de planification de requêtes qui tente d'éviter
  les recherches exhaustives. Activé par défaut. Divers paramètres GEQO_
  permettent d'en affiner le comportement.
  </entry>
  <entry>
  <para>
  GEQO a été introduit dans PostgreSQL 6.5 pour optimiser les requêtes de
  jointures qui utilisent trop de tables pour permettre une analyse exhaustive
  par le planificateur. C'était assez révolutionnaire, alors, mais n'a jamais
  été complètement optimisé. Depuis, sa maintenance est aléatoire. (NDR&nbsp;:
  Maintenant que de nouveaux CPU, plus rapides et plus de RAM, plus rapide, sont
  devenus accessible, je positionne le seuil GEQO aux environs de 20-25 tables.)
  Cela permet de s'assurer que GEQO n'est utilisé que lorsque c'est la seule
  solution. Il est évident que si PostgreSQL tourne sur une machine à CPU limité,
  le seuil GEQO peut être abaissé.
  </para>
  <para>
  GEQO peut être désactivé si aucune requête de cette complexité n'est jamais
  envisagée.
  </para>
  </entry>
 </row>
 <row>
  <entry>geqo_threshold</entry>
  <entry>2 à Int Max</entry>
  <entry></entry>
  <entry>11</entry>
  <entry>Oui</entry>
  <entry></entry>
  <entry>
  L'optimisation génétique de requête est utilisée pour planifier les requêtes
  qui contiennent au minimum ce nombre d'éléments dans la clause FROM. Une jointure
  compte pour un item FROM. La valeur par défaut est 11. Pour les requêtes plus
  simples, il est généralement plus efficace d'utiliser une stratégie de
  planification déterministique, exhaustive. Ce paramètre contrôle également la
  façon dont l'optimiseur tente de fusionner les sous-requêtes de clause FROM
  avec la requête principale.
  </entry>
  <entry></entry>
 </row>
 <row>
  <entry>
  <para>geqo_selection_bias</para>
  <para>geqo_pool_size</para>
  <para>geqo_effort</para>
  <para>geqo_generations</para>
  <para>geqo_random_seed</para>
  </entry>
  <entry>1.5-2.0</entry>
  <entry></entry>
  <entry>
  <para>2.0</para>
  <para>0</para>
  <para>1</para>
  <para>0</para>
  <para>-1</para>
  </entry>
  <entry>Oui</entry>
  <entry></entry>
  <entry>
  Divers paramètres d'affinage de l'algorithme d'optimisation génétique&nbsp;:
  la taille du <emphasis>pool</emphasis> correspond au nombre d'individus d'une population.
  L'échelle
  s'étend de 128 à 1024. Lorsqu'elle est positionnée à 0 (valeur par défaut), la
  taille du pool est obtenue par le calcul. Elle vaut alors 2^(QS+1), avec QS le
  nombre d'éléments FROM de la requête.
  L'<emphasis>effort</emphasis> est utilisé pour calculer une valeur par défaut pour les
  générations.
  L'échelle s'étend de 1 à 80, 40 étant la valeur par défaut.
  <emphasis>generations</emphasis> précise le nombre d'itérations de l'algorithme. Ce nombre
  doit être entier et positif. Si une valeur nulle est utilisée,
  <emphasis>generations</emphasis> est calculé. Le nombre vaut alors effort * Log2(PoolSize). 
  Le temps d'exécution de l'algorithme est approximativement proportionnel à la
  somme de la taille du <emphasis>pool</emphasis> et de <emphasis>generations</emphasis>. 
  <foreignphrase>selection bias</foreignphrase> affine la sélectivité au sein
  d'une population. Ses valeurs vont de 1.5 à 2.0 (2.0 étant la valeur
  par défaut).
  <foreignphrase>random seed</foreignphrase> permet d'ajuster l'algorithme pour
  obtenir des résultats reproductibles. Positionné à -1, l'algorithme a un
  comportement non déterministe.
  </entry>
  <entry></entry>
 </row>
</tbody>
</tgroup>
</table>

</sect2>

<sect2>
<title>Statistiques concernant les requêtes et les index</title>

<table>
<tgroup cols="8" align="left" colsep="1" rowsep="1">

<thead>
 <row>
  <entry>Paramètre</entry>
  <entry>&Eacute;chelle</entry>
  <entry>Ressources</entry>
  <entry>Valeur par défaut</entry>
  <entry>Positionnement</entry>
  <entry>-o</entry>
  <entry>Ce que dit la documentation</entry>
  <entry>Commentaires</entry>
 </row>
</thead>

<tbody>
 <row>
  <entry>
  <para>stats_start_collector</para>
  <para>stats_reset_on_server_start</para>
  <para>stats_command_string</para>
  <para>stats_row_level</para>
  <para>stats_block_level</para>
  </entry>
  <entry>true, false</entry>
  <entry>
  <para>true</para>
  <para>true</para>
  <para>false</para>
  <para>false</para>
  <para>false</para>
  </entry>
  <entry></entry>
  <entry>Non</entry>
  <entry></entry>
  <entry>
  Ces drapeaux détermine les informations envoyées par les serveurs au processus
  de collecte des statistiques&nbsp;: commande en cours, statistiques d'activité
  au niveau bloc ou statistiques d'activité au niveau ligne. Tous sont
  désactivés  par défaut. La collecte de statistiques coûte un peu de temps par
  requête, mais  est inestimable pour le débogage et l'optimisation des
  performances.
  </entry>
  <entry>
  NDR&nbsp;: J'écris un article sur Techdocs qui explique comment utiliser les
  statistiques de requête pour optimiser l'utilisation des index. Elles sont
  particulièrement utiles pour avoir une approche
  &laquo;&nbsp;déductive&nbsp;&raquo; de l'indexation, qui consiste à tout
  indexer  et supprimer ensuite les index inutiles.
  </entry>
 </row>
 <row>
  <entry>default_statistics_target</entry>
  <entry>1 -1000</entry>
  <entry></entry>
  <entry>10</entry>
  <entry>Oui</entry>
  <entry></entry>
  <entry>
  Positionne la cible par défaut des statistiques pour les tables dont la cible
  spécifique à la colonne n'a pas été positionnée à l'aide de ALTER TABLE SET
  STATISTICS. 
  Plus la valeur est grande, plus long est le temps nécessaire à l'ANALYZE.