Initialise le nombre de tampons en mémoire partagée utilisés par le serveur de bases de données. La valeur par défaut est de 1000 mais pourrait être moindre si la configuration de votre noyau ne le supporte pas (c'est déterminé lors de l'exécution d'initdb). Chaque tampon fait 8192 octets sauf si une valeur différente de BLCKSZ a été choisie lors de la construction du serveur. Ce paramétrage doit valoir au moins 16, mais aussi au moins deux fois la valeur de max_connections ; néanmoins, des valeurs significativement plus importantes que ce minimum sont généralement nécessaires pour de bonnes performances. Des valeurs de quelques milliers sont recommandées pour des installations de production. Cette option n'est initialisable qu'au lancement du serveur.
Augmenter ce paramètre pourrait faire en sorte que PostgreSQL™ réclame plus de mémoire partagé System V que ce que la configuration par défaut de votre système d'exploitation ne peut gérer. Voir la Section 16.4.1, « Mémoire partagée et sémaphore » pour plus d'informations sur l'ajustement de ces paramètres si nécessaire.
Configure le nombre maximum de tampons temporaires utilisés par chaque session de la base de données. Ce sont des tampons locaux au niveau de la session utilisés seulement pour accéder aux tables temporaires. La valeur par défaut est 1000. Ce paramètre peut être modifié à l'intérieur des sessions individuelles mais seulement jusqu'à la première utilisation des tables temporaires dans une session ; les tentatives suivantes de changement de cette valeur n'auront pas d'effet sur cette session.
Une session alloue les tampons temporaires nécessaires jusqu'à atteindre la limite donnée par temp_buffers. Le coût dû à une grosse valeur dans les sessions qui n'ont pas réellement besoin de beaucoup de tampons temporaires est seulement d'un descripteur de tampon, soit environ 64 octets, par incrément dans temp_buffers. Néanmoins, si un tampon est réellement utilisé, 8192 autres octets seront consommés pour ce dernier (ou, plus généralement, BLCKSZ octets).
Configure le nombre maximum de transactions pouvant être dans l'état « préparées » simultanément (voir PREPARE TRANSACTION). Configurer ce paramètre à zéro désactive la fonctionnalité des transactions préparées. La valeur par défaut est de 5. Cette fonctionnalité peut seulement être configurée au lancement du serveur.
Si vous n'utilisez pas les transactions préparées, ce paramètre peut valoir zéro. Si vous les utilisez, vous voudrez probablement que max_prepared_transactions soit au moins aussi important que max_connections pour éviter des échecs involontaires à l'étape de préparation.
Augmenter ce paramètre peut faire que PostgreSQL™ réclame plus de mémoire partagée System V que ne le permet la configuration par défaut de votre système d'exploitation. Voir la Section 16.4.1, « Mémoire partagée et sémaphore » pour des informations sur la façon d'ajuster ces paramètres, si nécessaire.
Spécifie la mémoire à utiliser pour les opérations de tri interne et pour les tables de découpage avant de basculer sur des fichiers temporaires sur disque. La valeur est spécifiée en Ko et vaut par défaut 1024 (soit 1 Mo). Notez que pour une requête complexe, plusieurs tris ou opérations de hachage pourraient être exécutés en parallèle ; chacun d'entre eux se verra autorisé à utiliser autant de mémoire que cette valeur indique avant de commencer à placer des données dans des fichiers temporaires. De plus, plusieurs sessions en cours d'exécution pourraient exécuter des opérations simultanément. Donc, la mémoire totale utilisée pourrait être plusieurs fois la valeur de work_mem ; il est nécessaire de conserver ce fait en tête lors du choix de cette valeur. Les opérations de tri sont utilisées pour ORDER BY, DISTINCT et les jointures de fusion. Les tables de découpage sont utilisées dans les jointures de découpage, les agrégations basées sur le découpage et le traitement des sous-requêtes IN.
Spécifie la mémoire maximum utilisée dans les opérations de maintenance telles que VACUUM, CREATE INDEX et ALTER TABLE ADD FOREIGN KEY. La valeur est spécifiée en Ko et vaut par défaut 16384 (soit 16 Mo). Comme une seule de ces opérations peut être exécutée à un moment donné sur une session de la base de données et qu'une installation n'en exécute pas beaucoup en même temps, il est possible d'initialiser cette variable à une valeur bien plus importante que work_mem. De gros paramétrages pourraient améliorer les performances sur les opérations VACUUM et pour la restauration des sauvegardes de bases de données.
Spécifie la profondeur maximum de la pile d'exécution du serveur. La configuration idéale pour ce paramètre est la limite actuelle de la pile forcée par le noyau (configurée par ulimit -s ou une commande locale équivalente), moins une marge de sécurité d'un Mo ou plus. La marge de sécurité est nécessaire parce que la profondeur de la pile n'est pas vérifiée dans chaque routine du serveur mais seulement dans les routines clés potentiellement récursives telles que l'évaluation d'une expression. Configurer ce paramètre à une valeur plus importante que la limite réelle du noyau signifiera qu'une fonction récursive peut arrêter brutalement un processus serveur individuel. Le paramétrage par défaut est de 2048 Ko (soit 2 Mo), ce qui est très petit et comporte peu de risques. Néanmoins, cela pourrait être trop petit pour autoriser l'exécution de fonctions complexes.
Ces paramètres contrôlent la taille de la carte de l'espace libre partagé, carte qui garde trace des emplacements inutilisés dans la base de données. Une carte de l'espace libre trop petite pourrait faire en sorte que la base de données se mette à consommer une place de plus en plus importante dans l'espace disque car l'espace libre qui n'est pas dans la carte ne peut pas être ré-utilisée ; à la place, PostgreSQL™ demandera plus d'espace disque au système d'exploitation lorsqu'il aura besoin de stocker de nouvelles données. Les quelques dernières lignes affichées suite à une commande VACUUM VERBOSE sur la base entière peut aider à déterminer si les paramètres en cours sont adéquats. Un message NOTICE est aussi affiché lors d'une telle opération si les paramètres en cours sont trop bas.
Augmenter ce paramètre pourrait faire que PostgreSQL™ réclame plus de mémoire partagée System V ou de sémaphores que ne le permet la configuration par défaut de votre système d'exploitation. Voir la Section 16.4.1, « Mémoire partagée et sémaphore » pour plus d'informations sur la façon d'ajuster ces paramètres si nécessaire.
Initialise le nombre maximum de pages disque pour lesquelles les espaces libres sont tracés dans la carte partagée des espaces libres. Six octets de mémoire partagée sont consommés pour chaque emplacement de page. Ce paramétrage doit être supérieur à 16 * max_fsm_relations. Par défaut, il est à 20000. Cette option n'est configurable qu'au lancement du serveur.
Initialise le nombre maximum de relations (tables et index) pour lesquelles les espaces libres sont tracés dans la carte partagée de l'espace libre. En gros, 70 octets de mémoire partagée sont consommés par emplacement. La valeur par défaut est de 1000. Cette option n'est configurable qu'au lancement du serveur.
Initialise le nombre maximum de fichiers ouverts simultanément permis pour chaque sous-processus serveur. La valeur par défaut est de 1000. Si le noyau force une limite par processus, vous n'avez pas besoin de vous inquiéter de ce paramétrage. Mais, sur certaines plateformes (notamment la plupart des systèmes BSD), le noyau autorisera des processus individuels à ouvrir beaucoup plus de fichiers que le système ne peut réellement supporter quand un grand nombre de processus essaient d'ouvrir autant de fichiers. Si vous récupérez des erreurs du type « Too many open files » (trop de fichiers ouverts), essayez de réduire ce paramètre. Cette option peut aussi être configurée au lancement du serveur.
Cette variable spécifie une ou plusieurs bibliothèques préchargées au lancement du serveur. Une fonction d'initialisation sans paramètre peut être appelée pour chaque bibliothèque. Pour cela, ajouter un caractère deux points et le nom de la fonction d'initialisation après le nom de la bibliothèque. Par exemple, '$libdir/malib:malib_init' causerait le préchargement de malib et l'exécution de malib_init. Si plus d'une bibliothèque doit être chargée, séparez leur nom par des virgules.
Si une bibliothèque spécifique ou une fonction d'initialisation sont introuvables, le serveur échouera au lancement.
Les bibliothèques des langages de procédure de PostgreSQL™ peuvent être préchargées de cette façon, typiquement en utilisant la syntaxe '$libdir/plXXX:plXXX_init' où XXX est soit pgsql soit perl soit tcl soit python.
En préchargeant une bibliothèque partagée (et en l'initialisant dans les cas applicables), le temps de lancement de la bibliothèque est évité à la première utilisation de la bibliothèque. Néanmoins, le temps de lancer chaque nouveau processus pourrait augmenter légèrement même si le processus n'utilise pas la bibliothèque. Donc, cette option est seulement recommandée pour les bibliothèques qui seront utilisées par la majorité des sessions.
Lors de l'exécution des commandes VACUUM et de ANALYZE, le système maintient un compteur interne conservant la trace du coût estimé des différentes opérations d'entrées/sorties réalisées. Quand le coût accumulé atteint une limite (spécifiée par vacuum_cost_limit), le processus traitant l'opération s'arrêtera un moment (spécifié par vacuum_cost_delay). Puis, il réinitialisera le compteur et continuera l'exécution.
Le but de cette fonctionnalité est d'autoriser les administrateurs à réduire l'impact des entrées/sorties de ces commandes suivant l'activité des bases de données. Il existe un grand nombre de situations pour lesquelles ceci n'est pas très important mais les commandes de maintenance quand VACUUM et ANALYZE se finissent rapidement ; néanmoins, il est généralement très important que ces commandes n'interfèrent pas de façon significative sur la capacité du système à réaliser d'autres opérations sur les bases de données. Un délai du VACUUM basé sur le coût fournit un moyen aux administrateurs pour y parvenir.
Cette fonctionnalité est désactivée par défaut. Pour l'activer, initialisez la variable vacuum_cost_delay à une valeur différente de zéro.
Le temps, en millisecondes, de repos du processus quand la limite de coût a été atteinte. La valeur par défaut vaut 0, ce qui désactive la fonctionnalité du délai du VACUUM basé sur le coût. Une valeur positive active cette fonctionnalité. Notez que, sur plusieurs systèmes, la résolution réelle des délais de repos est de 10 millisecondes ; configurer vacuum_cost_delay à une valeur qui n'est pas un multiple de 10 pourrait avoir le même résultat que de le configurer au prochain multiple de 10.
Le coût estimé pour nettoyer via VACUUM un tampon trouvé dans le cache des tampons partagés. Cela représente le coût pour verrouiller le lot de tampons, la recherche dans la table de découpage partagée et le parcours du contenu de la page. La valeur par défaut vaut 1.
Le coût estimé pour nettoyer via VACUUM un tampon qui doit être lu sur le disque. Ceci représente l'effort pour verrouiller le lot de tampons, la recherche dans la table de découpage partagée, la lecture du bloc désiré du disque et le parcours de son contenu. La valeur par défaut vaut 10.
Le coût estimé chargé quand VACUUM modifie un bloc qui était précédemment propre. Cela représente les entrées/sorties supplémentaires requis pour vider le bloc sale de nouveau sur le disque. La valeur par défaut vaut 20.
Le coût accumulé qui causera l'endormissement du processus de VACUUM. La valeur par défaut vaut 200.
![[Note]](images/note.png)
Certaines opérations contenant des verrous critiques devraient se terminer aussi rapidement que possible. Les délais de VACUUM basés sur le coût ne surviennent pas pendant ces opérations. Du coup, il est possible que le coût accumulé soit bien plus important que la limite spécifiée. Pour éviter des délais inutilement longs dans de tels cas, le délai réel est calculé de la façon suivante : vacuum_cost_delay * accumulated_balance / vacuum_cost_limit avec un maximum de vacuum_cost_delay * 4.
À partir de PostgreSQL™ 8.0, il existe un processus serveur séparé pour l'écriture en tâche de fond, dont la seule fonction est de lancer les écritures des tampons partagés « sales ». Le but est que les processus serveur gérant les requêtes des utilisateurs doivent déléguer ou n'avoir jamais à attendre la fin d'une écriture car le processus d'écriture en tâche de fond s'en chargera. Cet arrangement réduit aussi la pénalité de performance associée avec les points de vérification. Le processus d'écriture en tâche de fond vérifiera en contenu les pages sales pour les écrire sur le disque, de façon à ce que seules quelques pages doivent être forcées en écriture lorsque survient le point de vérification, à la place d'un déluge d'écritures de tampons sales ne se faisant qu'à chaque point de vérification. Néanmoins, il y a une nette augmentation dans la charge des entrées/sorties parce que, là où une page souvent sale n'aurait été écrite qu'une seule fois par intervalle de point de vérification, le processus d'écriture en tâche de fond l'aurait écrite plusieurs fois dans la même période. Dans la plupart des situations, un chargement lent continu est préférable à des pointes périodiques mais les paramètres discutés dans cette sous-section peuvent être utilisés pour configurer finement le comportement pour les besoins locaux.
Spécifie le délai entre les tours d'activité du processus d'écriture en tâche de fond. À chaque tour, le processus écrit un certain nombre de tampons sales (contrôlable par les paramètres suivants). Puis, il s'endort pour bgwriter_delay millisecondes et recommence. La valeur par défaut est de 200. Notez que sur de nombreux systèmes, la résolution réelle des délais de sommeil est de 10 millisecondes ; configurer bgwriter_delay à une valeur qui n'est pas un multiple de 10 pourrait avoir le même résultat que de le configurer au multiple de 10 supérieur. Cette option est disponible au lancement du serveur et dans le fichier postgresql.conf.
Pour réduire la probabilité que les processus serveur aient besoin de lancer leur propre écriture, la tâche de fond d'écriture essaie d'écrire les tampons qui ont une chance d'être rapidement recyclés. À chaque tour, elle examine jusqu'à bgwriter_lru_percent des tampons les plus proches du recyclage et écrit tout ce qui est à mettre à jour. La valeur par défaut est 1,0 (ceci est un pourcentage du nombre total de tampons partagés). Cette option peut être configurée au lancement du serveur et/ou dans le fichier postgresql.conf.
À chaque tour, ce nombre maximum de tampons sera écrit suite au parcours des prochains tampons à recycler. La valeur par défaut est de 5. Cette option peut être configurée au lancement du serveur et/ou dans le fichier postgresql.conf.
Pour réduire la quantité de travail nécessaire à chaque point de vérification, la tâche d'écriture en arrière plan fait aussi un parcours circulaire de l'ensemble des tampons, écrivant les tampons à mettre à jour. À chaque tour, il examine au plus bgwriter_all_percent des tampons dans ce but. La valeur par défaut est de 0,333 (ceci le pourcentage du nombre total de tampons partagés). Avec le paramètre par défaut bgwriter_delay, ceci permettra le parcours de l'ensemble de tampons une fois par minute. Cette option peut être configurée au lancement du serveur et/ou dans le fichier postgresql.conf.
À chaque tour, ce nombre maximum de tampons sera écrit suite au parcours de tous les tampons. (Si cette limite est atteinte, le parcours s'arrête et recommence au prochain tampon la prochaine fois.) La valeur par défaut est de 5. Cette option peut être configurée au lancement du serveur et/ou dans le fichier postgresql.conf.
Des valeurs plus petites de bgwriter_all_percent et bgwriter_all_maxpages réduiront la charge supplémentaire en entrées/sorties causée par le processus d'écriture en tâche de fond mais laisseront plus de travail aux points de vérification. Pour réduire les pointes de chargements aux points de vérification, augmentez ces deux valeurs. Pour désactiver totalement le processus en d'écriture en tâche de fond, configurez les deux valeurs maxpages et/ou les deux percent à zéro.
Connexions et
authentification