Initialise la quantité de mémoire que le serveur de bases de données utilise comme mémoire partagée. La valeur par défaut, en général 128 Mo, peut être automatiquement abaissée si la configuration du noyau ne la supporte pas (déterminé lors de l'exécution de l'initdb). Ce paramètre doit être au minimum de 128 ko + 16 ko par max_connections. Des valeurs significativement plus importantes que ce minimum sont généralement nécessaires pour de bonnes performances. Si cette valeur est spécifiée sans unité, elle sera interprétée comme un nombre de blocs, autrement dit BLCKSZ octets, typiquement 8 Ko. (Une valeur personnalisée de BLCKSZ changera la valeur minimale.) Ce paramètre ne peut être configuré qu'au lancement du serveur.

Si vous disposez d'un serveur dédié à la base de données, avec 1 Go de mémoire ou plus, une valeur de départ raisonnable pour ce paramètre est de 25% la mémoire de votre système. Certains cas peuvent nécessiter une valeur encore plus importante pour le shared_buffers mais comme PostgreSQL profite aussi du cache du système d'exploitation, il est peu probable qu'une allocation de plus de 40% de la mémoire fonctionnera mieux qu'une valeur plus restreinte. Des valeurs importantes pour le paramètre shared_buffers requièrent généralement une augmentation proportionnelle du max_wal_size, pour étendre dans le temps les écritures de grandes quantités de données, nouvelles ou modifiées.

Sur des systèmes comprenant moins d'1 Go de mémoire, un pourcentage plus restreint est approprié pour laisser une place suffisante au système d'exploitation.

Contrôle si les huge pages sont obligatoires pour la principale zone de mémoire partagée. Les valeurs valides sont try (le défaut), on et off. Avec huge_pages à try, le serveur tentera de demander des huge pages mais se rabattra sur le défaut en cas d'échec. Avec on, cet échec empêchera le serveur de démarrer. Avec off, il n'y aura pas de demande de huge pages. L'état réel des huge pages est indiqué par la variable huge_pages_status.

Pour le moment, ce paramètre n'est supporté que sur Linux et Windows. Il est ignoré sur les autres systèmes quand il est à try. Sur Linux, il est seulement supporté quand shared_memory_type est configuré à mmap (la valeur par défaut).

L'utilisation des huge pages réduit la taille des tables de pages et la consommation CPU pour gérer la mémoire, améliorant ainsi les performances. Pour plus de détails sur la gestion des huge pages sur Linux, voir Section 18.4.5.

Sous Windows, les huge pages sont connues sous le nom de large pages. Pour les utiliser, vous devez assigner le droit « Verrouiller les pages en mémoire » (Lock Pages in Memory) à l'utilisateur Windows qui fait tourner PostgreSQL. Vous pouvez utiliser l'Éditeur de stratégie de groupe locale (gpedit.msc) pour assigner ce droit à l'utilisateur. Pour démarrer le serveur en ligne de commande en tant que processus autonome, et pas en tant que service Windows, l'invite de commande doit tourner en tant qu'administrateur, ou bien le contrôle de compte d'utilisateur (UAC, User Access Control) doit être désactivé. Quand l'UAC est activé, l'invite de commande normale révoque le droit « Verrouiller les pages en mémoire » de l'utilisateur au démarrage.

Notez que ce paramètre n'affecte que la partie principale de la mémoire partagée. Des systèmes d'exploitation comme Linux, FreeBSD et Illumos peuvent aussi utiliser les huge pages automatiquement pour les allocations mémoire normales sans demande explicite de PostgreSQL. Sur Linux, cela s'appelle « transparent huge pages » (THP). Elles sont connues pour causer une dégradation des performances avec PostgreSQL pour certains utilisateurs sur certaines versions de Linux ; leur usage est donc actuellement déconseillé (au contraire de l'utilisation explicite de huge_pages).

Contrôle la taille des huge pages, quand elles sont activées avec huge_pages. La valeur par défaut est zéro (0). Si initialisé à 0, la valeur par défaut du système pour la taille des huge pages est utilisée.

Certaines valeurs communes de la taille des pages sur les serveurs à architecture 64 bits sont : 2MB et 1GB (Intel et AMD), 16MB et 16GB (IBM POWER), et 64kB, 2MB, 32MB et 1GB (ARM). Pour plus d'informations, voir Section 18.4.5.

L'utilisation de valeurs différentes des valeurs par défaut n'est actuellement supportée que sous Linux.

Configure la quantité maximale de mémoire utilisée pour le cache des objets temporaires à l'intérieur de chaque session à la base. Ce sont des caches locaux à la session utilisés uniquement pour l'accès aux tables temporaires. Si cette valeur est spécifiée sans unité, elle est interprétée comme un nombre de blocs, de BLCKSZ octets, typiquement 8 Ko. La valeur par défaut est de 8 Mo (8MB). (Si BLCKSZ ne vaut pas 8 Ko, la valeur changera de façon proportionnée.) Ce paramètre peut être modifié à l'intérieur de sessions individuelles mais seulement jusqu'à la première utilisation des tables temporaires dans une session ; les tentatives suivantes de changement de cette valeur n'ont aucun effet sur cette session.

Une session alloue des tampons temporaires en fonction des besoins jusqu'à atteindre la limite donnée par temp_buffers. Positionner une valeur importante pour les sessions qui ne le nécessitent pas ne coûte qu'un descripteur de tampon, soit environ 64 octets, par incrément de temp_buffers. Néanmoins, si un tampon est réellement utilisé, 8192 autres octets sont consommés pour celui-ci (ou, plus généralement, BLCKSZ octets).

Configure le nombre maximum de transactions simultanément dans l'état « préparées » (voir PREPARE TRANSACTION). Zéro, la configuration par défaut, désactive la fonctionnalité des transactions préparées Ce paramètre ne peut être configuré qu'au lancement du serveur.

Si vous ne prévoyez pas d'utiliser les transactions préparées, ce paramètre devrait être positionné à zéro pour éviter toute création accidentelle de transactions préparées. Au contraire, si vous les utilisez, il peut être intéressant de positionner max_prepared_transactions au minimum à au moins max_connections pour que chaque session puisse avoir sa transaction préparée.

Lors de l'exécution d'un serveur en attente, vous devez configurer ce paramètre à la même valeur ou à une valeur plus importante que sur le serveur primaire. Sinon, des requêtes pourraient ne pas être autorisées sur le serveur en attente.

Indique la quantité de mémoire maximale de base à utiliser pour l'exécution d'une requête (tel qu'un tri ou une table de hachage) avant d'écrire dans des fichiers temporaires sur disque. Si cette valeur est indiquée sans unité, elle est considérée être en Ko. La valeur par défaut est de 4 Mo (4MB). Une requête complexe peut réaliser plusieurs opérations de tri ou de hachage exécutées en même temps, chaque opération étant autorisée à utiliser autant de mémoire que cette valeur indique avant de commencer à écrire les données dans des fichiers temporaires. De plus, de nombreuses sessions peuvent exécuter de telles opérations simultanément. La mémoire totale utilisée peut, de ce fait, atteindre plusieurs fois la valeur de work_mem ; il est nécessaire de garder cela à l'esprit 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 hachage sont utilisées dans les jointures de hachage, les agrégations, les nœuds Memoize et le traitement des sous-requêtes IN fondés sur le hachage.

Les opérations basées sur le hachage sont généralement plus sensibles à la disponibilité de la mémoire que leur équivalent basé sur le tri. La mémoire disponible pour les tables de hachages est calculée en multipliant work_mem par hash_mem_multiplier. Cela rend possible pour les opérations de hachage d'utiliser une quantité de mémoire qui dépasse la quantité de base proposée par work_mem.

Utilisé pour calculer la quantité maximale de mémoire que les opérations basées sur le hachage peuvent utiliser. La limite finale est déterminée en multipliant work_mem par hash_mem_multiplier. La valeur par défaut est 2.0, ce qui rend les opérations de hachage sujettes au double de la valeur de work_mem pour les opérations basées sur le tri.

Pensez à augmenter hash_mem_multiplier dans les environnements où l'utilisation de fichiers temporaires survient fréquemment, tout spécialement quand augmenter uniquement work_mem a pour résultat une pression mémoire trop importante (la pression mémoire prend typiquement la forme d'erreurs pour manque de mémoire). La configuration par défaut de 2.0 est souvent efficace avec des charges de travail variées. Des configurations plus hautes (entre 2.0 et 8.0, voire encore plus) pourraient être plus efficaces dans les environnements où work_mem a déjà été augmenté à 40 Moi, voire plus.

Indique la quantité maximale de mémoire que peuvent utiliser les opérations de maintenance telles que VACUUM, CREATE INDEX et ALTER TABLE ADD FOREIGN KEY. Si cette valeur est indiquée sans unité, elle est considérée être en Ko. La valeur par défaut est de 64 Mo. Puisque seule une de ces opérations peut être exécutée à la fois dans une session et que, dans le cadre d'un fonctionnement normal, peu d'opérations de ce genre sont exécutées concurrentiellement sur une même installation, il est possible d'initialiser cette variable à une valeur bien plus importante que work_mem. Une grande valeur peut améliorer les performances des opérations VACUUM et de la restauration des sauvegardes.

Quand autovacuum fonctionne, un maximum de autovacuum_max_workers fois cette quantité de mémoire peut être utilisée. Il convient donc de s'assurer de ne pas configurer la valeur par défaut de façon trop importante. Il pourrait être utile de contrôler ceci en configurant autovacuum_work_mem séparément.

Indique la quantité maximale de mémoire à utiliser pour chaque processus autovacuum worker. Si cette valeur est indiquée sans unité, elle est considérée être en Ko. Ce paramètre vaut -1 par défaut, indiquant que la valeur de maintenance_work_mem doit être utilisée à la place. Ce paramétrage n'a pas d'effet sur le comportement de VACUUM lorsqu'il est exécuté dans d'autres contextes. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Indique la taille du Buffer Access Strategy utilisé par les commandes VACUUM et ANALYZE. Un paramétrage à 0 va autoriser l'opération à utiliser autant de shared_buffers que souhaité. Les tailles valides sont comprises entre 128 kB et 16 GB. Si la taille spécifiée dépasse 1/8 de la taille de shared_buffers, la taille sera plafonnée silencieusement à cette valeur. La valeur par défaut est 2 MB. Si cette valeur est indiquée sans unité, elle sera considérée comme étant des kilo-octets. Ce paramètre peut être modifié à tout instant. Il peut être surchargé pour VACUUM et ANALYZE en spécifiant l'option BUFFER_USAGE_LIMIT. Un paramétrage plus élevé permet aux commandes VACUUM et ANALYZE de s'exécuter plus rapidement, cependant, avoir une valeur trop élevée peut entrainer l'éviction d'autres blocs utiles de la mémoire partagée.

Indique la quantité de mémoire à utiliser pour le décodage logique, avant que certaines données décodées ne soient écrites sur les disques locaux. Ceci limite la quantité de mémoire utilisée par la réplication logique en flux. Elle vaut par défaut 64 Mo (64MB). Comme chaque connexion de réplication utilise un seul tampon de cette taille et qu'une installation ne peut avoir normalement beaucoup de connexions simultanées de ce type (étant donné qu'elles sont limitées par max_wal_senders), il est plus sûr de configurer cette valeur bien plus haute que work_mem, réduisant la quantité de données décodées écrites sur disque.

Précise la quantité de mémoire à utiliser pour le cache du contenu de pg_commit_ts (voir Tableau 66.1). Si cette valeur est indiquée sans unité, elle est prise pour un nombre de blocs, autrement dit BLCKSZ octets, soit typiquement 8 Ko. La valeur par défaut est 0, ce qui réclame de shared_buffers/512 à 1024 blocs, mais pas moins de 16 blocs. Ce paramètre peut seulement être configuré au démarrage du serveur.

Précise la quantité de mémoire partagée à utiliser pour le cache du contenu de pg_multixact/members (voir Tableau 66.1). Si cette valeur est indiquée sans unité, elle est prise pour un nombre de blocs, autrement dit BLCKSZ octets, soit typiquement 8 Ko. La valeur par défaut est 32. Ce paramètre peut seulement être configuré au démarrage du serveur.

Précise la quantité de mémoire partagée à utiliser pour le cache du contenu de pg_multixact/offsets (voir Tableau 66.1). Si cette valeur est indiquée sans unité, elle est prise pour un nombre de blocs, autrement dit BLCKSZ octets, soit typiquement 8 Ko. La valeur par défaut est 16. Ce paramètre peut seulement être configuré au démarrage du serveur.

Précise la quantité de mémoire partagée à utiliser pour le cache du contenu de pg_notify (voir Tableau 66.1). Si cette valeur est indiquée sans unité, elle est prise pour un nombre de blocs, autrement dit BLCKSZ octets, soit typiquement 8 Ko. La valeur par défaut est 16. Ce paramètre peut seulement être configuré au démarrage du serveur.

Précise la quantité de mémoire partagée à utiliser pour le cache du contenu de pg_serial (voir Tableau 66.1). Si cette valeur est indiquée sans unité, elle est prise pour un nombre de blocs, autrement dit BLCKSZ octets, soit typiquement 8 Ko. La valeur par défaut est 32. Ce paramètre peut seulement être configuré au démarrage du serveur.

Précise la quantité de mémoire partagée à utiliser pour le cache du contenu de pg_subtrans (voir Tableau 66.1). Si cette valeur est indiquée sans unité, elle est prise pour un nombre de blocs, autrement dit BLCKSZ octets, soit typiquement 8 Ko. La valeur par défaut est 0, ce qui réclame de shared_buffers/512 à 1024 blocs, mais pas moins de 16 blocs. Ce paramètre peut seulement être configuré au démarrage du serveur.

Précise la quantité de mémoire partagée à utiliser pour le cache du contenu de pg_xact (voir Tableau 66.1). Si cette valeur est indiquée sans unité, elle est prise pour un nombre de blocs, autrement dit BLCKSZ octets, soit typiquement 8 Ko. La valeur par défaut est 0, ce qui réclame de shared_buffers/512 à 1024 blocs, mais pas moins de 16 blocs. Ce paramètre peut seulement être configuré au démarrage du serveur.

Indique la profondeur maximale de la pile d'exécution du serveur. La configuration idéale pour ce paramètre est la limite réelle de la pile assurée par le noyau (configurée par ulimit -s ou équivalent local) à laquelle est soustraite une marge de sécurité d'un Mo environ. 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 uniquement dans les routines clés potentiellement récursives. Si cette valeur est indiquée sans unité, elle est considérée être en Ko. Le paramétrage par défaut est de 2 Mo, valeur faible qui implique peu de risques. Néanmoins, elle peut s'avérer trop petite pour autoriser l'exécution de fonctions complexes. Seuls les superutilisateurs et les utilisateurs disposant des droits SET appropriés peuvent modifier ce paramètre.

Configurer ce paramètre à une valeur plus importante que la limite réelle du noyau signifie qu'une fonction récursive peut occasionner un arrêt brutal d'un processus serveur particulier. Sur les plateformes où PostgreSQL peut déterminer la limite du noyau, il interdit de positionner cette variable à une valeur inadéquate. Néanmoins, toutes les plateformes ne fournissent pas cette information, et une grande attention doit être portée au choix de cette valeur.

Indique l'implémentation de mémoire partagée que le serveur doit utiliser pour la principale région de mémoire partagée contenant le cache disque de PostgreSQL et d'autres données partagées. Les valeurs possibles sont mmap (pour la mémoire partagée anonyme allouée en utilisant mmap), sysv (pour la mémoire partagée System V allouée via shmget) et windows (pour la mémoire partagée Windows). Toutes les valeurs ne sont pas forcément supportées sur toutes les plateformes ; la première option supportée est la valeur par défaut pour cette plateforme. L'utilisation de l'option sysv, qui n'est pas la valeur par défaut quelque soit la plateforme, est généralement non conseillée car elle nécessite habituellement une configuration du noyau différente de la configuration par défaut pour permettre de grosses allocations (voir Section 18.4.1).

Indique l'implémentation de mémoire partagée dynamique que le serveur doit utiliser. Les valeurs possibles sont posix (pour la mémoire partagée POSIX allouée en utilisant shm_open), sysv (pour la mémoire partagée System V allouée en* utilisant shmget), windows (pour la mémoire partagée Windows), mmap (pour simuler la mémoire partagée en utilisant les fichiers de mémoire enregistrés dans le répertoire des données). Toutes les valeurs ne sont pas forcément supportées sur toutes les plateformes ; la première option supportée est la valeur par défaut pour cette plateforme. L'utilisation de l'option mmap, qui n'est la valeur par défaut d'aucune plateforme, est généralement déconseillée car le système d'exploitation pourrait écrire des pages modifiées sur disque de manière répétée, augmentant la charge disque du système. Néanmoins, cela peut se révéler utile pour débugger, quand le répertoire pg_dynshmem est stocké dans un disque RAM ou quand les autres options de mémoire partagée ne sont pas disponibles.

Indique la quantité de mémoire qui doit être allouée au démarrage du serveur pour l'execution en parallèle de requêtes. Quand cette partie de la mémoire est insuffisante pour les requêtes concurrentes, de nouvelles requêtes parallèles essayent d'allouer temporairement plus de mémoire partagée en utilisant la méthode configurée avec dynamic_shared_memory_type, ce qui peut être plus lent à cause de la consommation de ressources de la gestion de la mémoire. La mémoire allouée au démarrage avec min_dynamic_shared_memory est affectée par le paramètre huge_pages au niveau du système d'exploitation lorsque c'est supporté et peut bénéficier de plus grandes pages sur les systèmes d'exploitation où c'est géré automatiquement. La valeur par défaut est 0 (aucune).

Spécifie la quantité maximale d'espace disque qu'un processus peut utiliser pour les fichiers temporaires, comme par exemple ceux utilisés pour les tris et hachages, ou le fichier de stockage pour un curseur détenu. Une transaction tentant de dépasser cette limite sera annulée. La valeur a pour unité le ko. La valeur spéciale -1 (valeur par défaut) signifie sans limite. Seuls les superutilisateurs et les utilisateurs disposant des droits SET appropriés peuvent modifier cette configuration.

Ce paramètre contraint l'espace total utilisé à tout instant par tous les fichiers temporaires utilisés pour un processus PostgreSQL donnée. Il doit être noté que l'espace disque utilisé pour les tables temporaires explicites, à l'opposé des fichiers temporaires utilisés implicitement pour l'exécution des requêtes, n'est pas pris en compte pour cette limite.

Spécifie la méthode utilisée pour copier des fichiers. Les valeurs possibles sont COPY (la valeur par défaut) et CLONE (si le support au niveau système est disponible).

Ce paramètre affecte :

CLONE utilise les appels systèmes copy_file_range() (Linux, FreeBSD) ou copyfile (macOS), donnant au noyau l'opportunité de partager les blocs disques ou de donner ce travail aux couches basses sur certains systèmes de fichiers.

Précise la quantité maximale de blocs alloués pour la queue NOTIFY / LISTEN. La valeur par défaut est 1048576. Pour des blocs de 8 Ko, cela permet de consommer jusqu'à 8 Go d'espace disque.

Configure le nombre maximum de fichiers ouverts que chaque processus serveur se voit autoriser à ouvrir simultanément ; les fichiers déjà ouverts par postmaster ne sont pas comptés pour cette limite. La valeur par défaut est de mille fichiers.

Si le noyau assure une limite par processus, il n'est pas nécessaire de s'intéresser à ce paramètre. Toutefois, sur certaines plateformes (notamment les systèmes BSD) le noyau autorise les processus individuels à ouvrir plus de fichiers que le système ne peut effectivement en supporter lorsqu'un grand nombre de processus essayent tous d'ouvrir ce nombre de fichiers. Si le message « Too many open files » (« Trop de fichiers ouverts ») apparaît, il faut essayer de réduire ce paramètre. Ce paramètre ne peut être configuré qu'au lancement du serveur.

Précise le délai de réveil du processus background writer. À chaque réveil, le processus écrit un certain nombre de blocs modifiés (nombre contrôlable par les paramètres qui suivent). Il dort ensuite pendant un délai configuré avec le paramètre bgwriter_delay, puis recommence. Quand il n'y a plus de blocs modifiés dans le cache disque de PostreSQL, il entre dans une phase de sommeil profond, qui ne dépend pas de la valeur de bgwriter_delay. Si la valeur de ce paramètre n'a pas d'unité, la valeur est prise pour des millisecondes. La valeur par défaut est de 200 millisecondes (200ms). Notez que sur certains systèmes, la résolution effective du délai d'endormissement est de 10 millisecondes ; une configuration de bgwriter_delay à une valeur qui n'est pas un multiple de 10 pourrait avoir le même résultat qu'une configuration à la dizaine supérieure. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

À chaque réveil, ce nombre maximum de blocs sera écrit par le processus background writer. Configurer ce paramètre à zéro désactive l'écriture en tâche de fond. (Notez que les checkpoints, qui sont gérés par un processus auxiliaire séparé, ne sont pas affectés.) La valeur par défaut est de 100 blocs. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Le nombre de blocs modifiés écrits à chaque réveil est basé sur le nombre de nouveaux blocs qui ont été nécessaires aux processus serveur durant les réveils récents. Le besoin récent moyen est multiplié par bgwriter_lru_multiplier pour arriver à une estimation du nombre de blocs qui seront nécessaire jusqu'au prochain réveil. Les blocs modifiés sont écrits jusqu'à ce qu'il y ait de disponible ce nombre de blocs propres, réutilisables. (Néanmoins, pas plus de bgwriter_lru_maxpages ne seront écrits par réveil.) De ce fait, une configuration à 1.0 représente une politique d'écriture au minimum, correspondant à exactement le nombre de blocs supposés nécessaires. Des valeurs plus importantes fournissent une marge contre les pics de demande alors que des valeurs plus basses vont intentionnellement forcer les processus serveur à réaliser des écritures. La valeur par défaut est 2.0. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Quand plus de cette quantité de données a été écrit par le processus background writer, essaie de forcer le système d'exploitation à vider son cache sur disque. Faire cela limite la quantité de données modifiées dans le cache du système d'exploitation, réduisant la probabilité de blocage quand un fsync est lancé à la fin d'un checkpoint ou quand le système d'exploitation écrit les données dans de gros batchs en tâche de fond. Souvent, cela résultera en une latence fortement réduite des transactions, mais il existe aussi certains, tout spécialement avec les charges de travail plus importantes que shared_buffers, mais plus petite que le cache du système d'exploitation, où les performances pourraient être dégradées. Ce paramètre peut n'avoir aucun effet sur certaines plateformes. Si cette valeur est indiquée sans unité, elle est considérée comme un nombre de blocs (un bloc fait BLCKSZ octets, typiquement 8 Ko). L'intervalle valide est entre 0, qui désactive le vidage forcé, et 2MB. La valeur par défaut est 512kB sur Linux, 0 ailleurs. (Si BLCKSZ ne vaut pas 8 Ko, les valeurs par défaut et maximale augmentent proportionnellement.) Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Quand plus de cette quantité de données a été écrit par un seul processus serveur, essaie de forcer le système d'exploitation à vider son cache sur disque. Faire cela limite la quantité de données modifiées dans le cache du système d'exploitation, réduisant la probabilité de blocage quand un fsync est lancé à la fin d'un checkpoint ou quand le système d'exploitation écrit les données dans de gros batchs en tâche de fond. Souvent, cela résultera en une latence fortement réduite des transactions, mais il existe aussi certains, tout spécialement avec les charges de travail plus importantes que shared_buffers, mais plus petite que le cache du système d'exploitation, où les performances pourraient être dégradées. Ce paramètre peut n'avoir aucun effet sur certaines plateformes. Si cette valeur est indiquée sans unité, elle est considérée comme un nombre de blocs (un bloc fait BLCKSZ octets, typiquement 8 Ko). L'intervalle valide est entre 0, qui désactive le vidage forcé, et 2MB. La valeur par défaut est 512kB sur Linux, 0 ailleurs. (Si BLCKSZ ne vaut pas 8 Ko, les valeurs par défaut et maximale augmentent proportionnellement.)

Configure le nombre d'opérations d'entrées/sorties disques concurrentes que PostgreSQL s'attend à voir exécuter simultanément. Augmenter cette valeur va accroître le nombre d'opérations d'entrées/sorties disques qu'une session PostgreSQL individuelle essaie de lancer en parallèle. L'intervalle autorisée va de 1 à 1000, ou 0 pour désactiver l'envoi de demandes asynchrones d'entrées/sorties disques. La valeur par défaut est 16.

Les valeurs hautes auront le plus d'impact sur des stockages dont la latence est haute (et donc où les demandes produisent sinon des blocages dans les accès au disque), ainsi que sur des périphériques dont l'IOPS est élevé. Des valeurs inutilement hautes augmenteront les latences sur les entrées/sorties disques pour toutes les demandes du système.

Sur les systèmes acceptant les demandes de lectures en avance, effective_io_concurrency contrôle aussi la distance du prefetch.

Cette valeur peut être surchargée pour les tables d'un tablespace particulier avec le paramètre du même nom (voir ALTER TABLESPACE).

Similaire à effective_io_concurrency, mais utilisé pour le travail de maintenance fait au nom de plusieurs autres sessions clients.

La valeur par défaut est 16. Cette valeur peut être surchargée pour les tables d'un tablespace particulier avec le paramètre du même nom (voir ALTER TABLESPACE).

Contrôle la plus grande taille d'entrée/sorties disque dans les opérations qui combinent les entrées/sorties disques, et limite silencieusement le paramètre io_combine_limit configurable par un utilisateur. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur. La taille maximale possible dépend du système d'exploitation et de la taille d'un bloc, mais il est typiquement de 1 Mo sur Unix et de 128 Ko sur Windows. La valeur par défaut est 128 Ko.

Contrôle la plus grande taille des opérations d'entrées/sorties disques pour les opérations qui se combinent. Si configuré à une valeur plus haute que le paramètre io_max_combine_limit, la valeur la plus basse sera utilisée silencieusement à la place, donc les deux pourraient avoir besoin d'être augmentés pour accroître la taille des entrées/sorties disques. La taille maximale possible dépend du système d'exploitation et de la taille d'un bloc, mais il est typiquement de 1 Mo sur Unix et de 128 Ko sur Windows. La valeur par défaut est 128 Ko.

Contrôle le nombre maximum d'opérations d'entrées/sorties disques qu'un processus peut exécuter simultanément.

La configuration par défaut de -1 sélectionne un nombre basé sur shared_buffers et sur le nombre maximum de processus (max_connections, autovacuum_worker_slots, max_worker_processes et max_wal_senders), mais jamais plus de 64.

Ce paramètre peut seulement être configuré au démarrage du serveur.

Sélectionne la méthode pour exécuter des entrées/sorties disques asynchrones. Les valeurs possibles sont :

La valeur par défaut est worker.

Ce paramètre peut seulement être configuré au démarrage.

Sélectionne le nombre de processus auxiliaires pour les entrées/sorties disques. La valeur par défaut est 3. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Ce paramètre n'est pris en compte que si io_method est configuré à worker.

Configure le nombre maximum de background workers acceptés par le système. Ce paramètre n'est configurable qu'au démarrage du serveur. La valeur par défaut est 8.

S'il s'agit de la configuration d'un serveur secondaire, vous devez configurer ce paramètre à une valeur supérieure ou égale à celui du serveur primaire. Dans le cas contraire, il ne sera pas possible d'exécuter des requêtes sur le serveur secondaire.

Configure le nombre maximum de processus parallèles pouvant être lancé par un seul nœud Gather ou Gather Merge. Les processus parallèles sont pris dans l'ensemble de processus établi par max_worker_processes, limité par max_parallel_workers. Notez que le nombre demandé de processus parallèles pourrait ne pas être disponible à l'exécution. Si cela survient, le plan s'exécutera avec moins de processus qu'attendu, ce qui pourrait être inefficace. La valeur par défaut est 2. Positionner cette valeur à 0 désactive l'exécution parallélisée de requête.

Notez que les requêtes parallélisées peuvent consommer considérablement plus de ressources que des requêtes non parallélisées parce que chaque processus parallèle est un processus totalement séparé qui a en gros le même impact sur le système qu'une session utilisateur supplémentaire. Ceci doit être pris en considération lors du choix d'une valeur pour ce paramètre, ainsi que lors de la configuration d'autres paramètres qui contrôlent l'utilisation des ressources, comme par exemple work_mem. Les limites de ressources comme work_mem sont appliquées individuellement pour chaque processus, ce qui signifie que l'utilisation totale pourrait être bien plus importante que pour un seul processus. Par exemple, une requête parallélisée utilisant quatre processus pourrait utiliser jusqu'à cinq fois plus de CPU, de mémoire, de bande passante disque, et ainsi de suite qu'une requête non parallélisée.

Pour plus d'informations sur les requêtes parallélisées, voir Chapitre 15.

Indique le nombre maximum de workers parallèles qu'une commande utilitaire peut démarrer. Actuellement, les commandes utilitaires qui supportent les workers parallèles est CREATE INDEX pour la création d'un index B-tree, GIN ou BRIN, et VACUUM sans l'option FULL. Les workers parallèles sont déduits du pool de processus défini par max_worker_processes, dans la limite de max_parallel_workers. Notez que le nombre de workers demandé peut ne pas être disponible lors de l'exécution. Si cela arrive, l'opération utilitaire fonctionnera avec moins de workers qu'attendu. Le défaut est de 2. Passer cette valeur à 0 désactive l'utilisation des workers parallèles par les commandes utilitaires.

Notez que les commandes utilitaires parallélisées ne devraient pas consommer beaucoup plus de mémoire que leur équivalent non parallélisé. Cette stratégie diffère de celle adoptée pour les requêtes parallélisées, où les limites de ressources s'appliquent généralement par processus (worker). Les commandes utilitaires parallélisées traitent la limite de ressource maintenance_work_mem comme une limite à appliquer à la commande entière, sans considération du nombre de workers parallèles. Cependant, les commandes utilitaires parallélisées peuvent consommer nettement plus de CPU et de bande passante.

Positionne le nombre maximum de workers que l'instance peut supporter pour le besoin des requêtes parallèles. La valeur par défaut est 8. Lorsque cette valeur est augmentée ou diminuée, pensez également à modifier max_parallel_maintenance_workers et max_parallel_workers_per_gather. De plus, veuillez noter que positionner cette valeur plus haut que max_worker_processes n'aura pas d'effet puisque les workers parallèles sont pris de la réserve de processus établie par ce paramètre.

Permet au processus leader d'exécuter le plan de la requête sur les nœuds Gather et Gather Merge au lieu d'attendre le processus en cours. Positionner ce paramètre à off réduit la probabilité qu'un processus soit bloqué parce que le processus leader ne lit pas les données assez vite mais impose que le processus leader attende que les autres processus aient démarré avant que les premières lignes ne soient produites. Le degré à partir duquel le processus leader peut améliorer ou détériorer les performances dépend du type de plan d'exécution, du nombre de processus parallèles et de la durée d'exécution de la requête.