Ces paramètres de configuration fournissent une méthode brutale pour
influencer les plans de requête choisis par l'optimiseur de requêtes.
Si le plan choisi par défaut par l'optimiseur pour une requête
particulière n'est pas optimal, une solution
temporaire peut provenir de l'utilisation de l'un
de ces paramètres de configuration pour forcer l'optimiseur à choisir
un plan différent. De meilleures façons d'améliorer la qualité des
plans choisis par l'optimiseur passent par l'ajustement des constantes
de coût du planificateur (voir Section 19.7.2), le lancement plus fréquent
de ANALYZE, l'augmentation de la valeur du
paramètre de configuration default_statistics_target et l'augmentation du nombre
de statistiques récupérées pour des colonnes spécifiques en utilisant
ALTER TABLE SET STATISTICS
.
enable_bitmapscan
(boolean
)
Active ou désactive l'utilisation des plans de parcours de bitmap
(bitmap-scan) par
le planificateur de requêtes. Activé par défaut (on
).
enable_gathermerge
(boolean
)
Active ou désactive l'utilisation des plans de type gather merge.
La valeur par défaut est on
.
enable_hashagg
(boolean
)
Active ou désactive l'utilisation des plans d'agrégation hachée
(hashed aggregation) par le
planificateur. Activé par défaut (on
).
enable_hashjoin
(boolean
)
Active ou désactive l'utilisation des jointures de hachage
(hash-join) par le
planificateur. Activé par défaut (on
).
enable_incremental_sort
(boolean
)
Active ou désactive l'utilisation des tris incrémentaux par le
planificateur. La valeur par défaut est on
.
enable_indexscan
(boolean
)
Active ou désactive l'utilisation des parcours d'index
(index-scan) par le
planificateur. Activé par défaut (on
).
enable_indexonlyscan
(boolean
)
Active ou désactive l'utilisation des parcours d'index seuls
(index-only-scan) par le planificateur
(voir Section 11.9). Activé par défaut
(on
).
enable_material
(boolean
)
Active ou désactive l'utilisation de la matérialisation par le
planificateur. Il est impossible de supprimer complètement son
utilisation mais la désactivation de cette variable permet d'empêcher
le planificateur d'insérer des nœuds de matérialisation sauf
dans le cas où son utilisation est obligatoire pour des raisons de
justesse de résultat. Activé par défaut (on
).
enable_mergejoin
(boolean
)
Active ou désactive l'utilisation des jointures de fusion
(merge-join)par le
planificateur. Activé par défaut (on
).
enable_nestloop
(boolean
)
Active ou désactive l'utilisation des jointures de boucles imbriquées
(nested-loop)
par le planificateur. Il n'est pas possible de supprimer
complètement les jointures de boucles imbriquées mais la
désactivation de cette variable décourage le planificateur d'en
utiliser une si d'autres méthodes sont disponibles.
Activé par défaut (on
).
enable_parallel_append
(boolean
)
Active ou désactive l'utilisation de plans Append parallélisés.
La valeur par défaut est on
.
enable_parallel_hash
(boolean
)
Active ou désactive l'utilisation des plans parallélisés de jointure
par hachage. N'a pas d'effet si les plans de jointure par hachage ne
sont pas activés. La valeur par défaut est
on
.
enable_partition_pruning
(boolean
)
Active ou désactive la capacité du planificateur à éliminer les
partitions d'une table partitionnée dans les plans d'exécution. Cela
contrôle aussi la capacité du planificateur à générer des plans de
requête autorisant l'exécuteur à supprimer (ignorer) les partitions
durant l'exécution. Le défaut est on
.
Voir Section 5.11.4 pour les détails.
enable_partitionwise_join
(boolean
)
Active ou désactive l'utilisation par le planificateur des jointures
entre partitions, qui permettent aux jointures entre tables partitionnées
d'être effectuées en joignant les partitions correspondantes. Pour le
moment, une jointure entre partitions ne s'applique que si la condition de
jointure inclut toutes les clés de partition, qui doivent être du même
type et avoir exactement les mêmes ensembles de partitions filles.
Avec ce paramètre activé, le nombre de nœuds dont l'utilisation
mémoire est restreinte par work_mem
apparaissant dans
le plan final peut augmenter de façon linéaire suivant le nombre de partitions
parcourues. Ceci peut engendrer une forte augmentation de la consommation de
la mémoire globale lors de l'exécution de la requête. La planification de
requête devient aussi significativement plus coûteuse en terme de mémoire et
de CPU. La valeur par défaut est off
.
enable_partitionwise_aggregate
(boolean
)
Active ou désactive l'utilisation par le planificateur des regroupements
ou agrégations par partition, qui permettent, dans les tables
partitionnées, d'exécuter regroupement ou agrégation séparément pour
chaque partition. Si la clause GROUP BY
n'inclut pas
les clés de partition, seule une agrégation partielle peut être
effectuée par partition, et la finalisation interviendra plus tard.
Avec ce paramètre activé, le nombre de nœuds dont l'utilisation
mémoire est restreinte par work_mem
apparaissant dans
le plan final peut augmenter de façon linéaire suivant le nombre de partitions
parcourues. Ceci peut engendrer une forte augmentation de la consommation de
la mémoire globale lors de l'exécution de la requête. La planification de
requête devient aussi significativement plus coûteuse en terme de mémoire et
de CPU. La valeur par défaut est off
.
enable_seqscan
(boolean
)
Active ou désactive l'utilisation des parcours séquentiels
(sequential scan) par le
planificateur. Il n'est pas possible de supprimer complètement les
parcours séquentiels mais la désactivation de cette variable décourage le
planificateur d'n utiliser un si d'autres méthodes sont disponibles.
Activé par défaut (on
).
enable_sort
(boolean
)
Active ou désactive l'utilisation des étapes de tri explicite par le
planificateur. Il n'est pas possible de supprimer complètement ces tris
mais la désactivation de cette variable décourage le planificateur
d'en utiliser un si d'autres méthodes sont disponibles. Activé par défaut
(on
).
enable_tidscan
(boolean
)
Active ou désactive l'utilisation des parcours de TID par
le planificateur. Activé par défaut (on
).
Les variables de coût décrites dans cette section
sont mesurées sur une échelle arbitraire. Seules leurs valeurs relatives
ont un intérêt. De ce fait, augmenter ou diminuer leurs valeurs d'un même facteur
n'occasione aucun changement dans les choix du planificateur.
Par défaut, ces variables de coût sont basées sur le coût de
récupération séquentielle d'une page ; c'est-à-dire que
seq_page_cost
est, par convention, positionné à
1.0
et les autres variables de coût sont configurées
relativement à cette référence. Il est toutefois possible d'utiliser
une autre échelle, comme les temps d'exécution réels en millisecondes sur
une machine particulière.
Il n'existe malheureusement pas de méthode bien définie pour déterminer les valeurs idéales des variables de coût. Il est préférable de les considérer comme moyennes sur un jeu complet de requêtes d'une installation particulière. Cela signifie que modifier ces paramètres sur la seule base de quelques expériences est très risqué.
seq_page_cost
(floating point
)Initialise l'estimation faite par le planificateur du coût de récupération d'une page disque incluse dans une série de récupérations séquentielles. La valeur par défaut est 1.0. Cette valeur peut être surchargée pour les tables et index d'un tablespace spécifique en configurant le paramètre du même nom pour un tablespace (voir ALTER TABLESPACE).
random_page_cost
(floating point
)Initialise l'estimation faite par le planificateur du coût de récupération non-séquentielle d'une page disque. Mesurée comme un multiple du coût de récupération d'une page séquentielle, sa valeur par défaut est 4.0. Cette valeur peut être surchargée pour les tables et index d'un tablespace spécifique en configurant le paramètre du même nom pour un tablespace (voir ALTER TABLESPACE).
Réduire cette valeur par rapport à seq_page_cost
incite le système à privilégier les parcours d'index ;
l'augmenter donne l'impression de parcours d'index plus
coûteux. Les deux valeurs peuvent être augmentées ou diminuées
concomitament pour modifier l'importance des coûts d'entrées/sorties disque
par rapport aux coûts CPU, décrits par les paramètres qui suivent.
Les accès aléatoires sur du stockage mécanique sont généralement bien plus coûteux que quatre fois un accès séquentiel. Néanmoins, une valeur plus basse est utilisée (4,0) car la majorité des accès disques aléatoires, comme les lectures d'index, est supposée survenir en cache. La valeur par défaut peut être vu comme un modèle d'accès aléatoire 40 fois plus lent que l'accès séquentiel, en supposant que 90% des lectures aléatoires se font en cache.
Si vous pensez qu'un taux de 90% est incorrect dans votre cas, vous pouvez
augmenter la valeur du paramètre random_page_cost pour que cela
corresponde mieux au coût réel d'un accès aléatoire. De la même façon, si
vos données ont tendance à être entièrement en cache (par exemple quand
la base de données est plus petite que la quantité de mémoire du serveur),
diminuer random_page_cost peut être approprié. Le stockage qui a un coût
de lecture aléatoire faible par rapport à du séquentiel (par exemple les
disques SSD) peut aussi être mieux tenu en compte avec une valeur plus
faible pour random_page_cost, par exemple 1.1
.
Bien que le système permette de configurer
random_page_cost
à une valeur inférieure à celle
de seq_page_cost
, cela n'a aucun intérêt.
En revanche, les configurer à des valeurs identiques prend tout son
sens si la base tient entièrement dans le cache en RAM. En effet, dans ce
cas, il n'est pas pénalisant d'atteindre des pages qui ne se suivent
pas. De plus, dans une base presque entièrement en cache, ces valeurs
peuvent être abaissées relativement aux paramètres CPU car le coût de
récupération d'une page déjà en RAM est bien moindre à celui de sa
récupération sur disque.
cpu_tuple_cost
(floating point
)Initialise l'estimation faite par le planificateur du coût de traitement de chaque ligne lors d'une requête. La valeur par défaut est 0.01.
cpu_index_tuple_cost
(floating point
)Initialise l'estimation faite par le planificateur du coût de traitement de chaque entrée de l'index lors d'un parcours d'index. La valeur par défaut est 0.005.
cpu_operator_cost
(floating point
)Initialise l'estimation faite par le planificateur du coût de traitement de chaque opérateur ou fonction exécutée dans une requête. La valeur par défaut est 0.0025.
parallel_setup_cost
(floating point
)
Configure le coût estimé par l'optimiseur pour le lancement de processus de travail parallèle. La valeur par défaut est 1000.
parallel_tuple_cost
(floating point
)
Configure le coût estimé par l'optimiseur pour le transfert d'une ligne d'un processus de travail parallèle à un autre. La valeur par défaut est 0,1.
min_parallel_table_scan_size
(integer
)
Spécifie la quantité minimale de donnée de la table qui doit être
parcourue pour qu'un parcours parallèle soit envisagé. Pour un
parcours séquentiel parallèle, la quantité de données de la table
parcourue est toujours égale à la taille de la table, mais quand des
index sont utilisés la quantité de données de la table parcourue sera
normalement moindre. Si cette valeur est spécifiée sans unité, elle
est comprise comme un nombre de blocs, autrement dit
BLCKSZ
octets, typiquement 8 Ko. La valeur par défaut
est 8 Mo (8MB
).
min_parallel_index_scan_size
(integer
)
Spécifie la quantité minimale de donnée d'index qui doit être
parcourue pour qu'un parcours parallèle soit envisagé. Veuillez noter
qu'un parcours d'index parallèle ne touchera en général pas la
totalité de l'index ; il s'agit du nombre de page que
l'optimisateur pensera réellement toucher durant le parcours qui est
important. Ce paramètre est aussi utilisé pour décider si un index
particulier peut participer à un vacuum parallélisé. Voir VACUUM. Si cette valeur est spécifiée sans unité, elle
est comprise comme un nombre de blocs, autrement dit
BLCKSZ
octets, typiquement 8 Ko. La valeur par défaut
est 512 kilooctets (512kB
).
effective_cache_size
(integer
)
Initialise l'estimation faite par le planificateur de la taille
réelle du cache disque disponible pour une requête. Ce paramètre est
lié à l'estimation du coût d'utilisation d'un index ; une valeur
importante favorise les parcours d'index, une valeur faible les
parcours séquentiels. Pour configurer ce paramètre, il est important
de considérer à la fois les tampons partagés de
PostgreSQL et la portion de cache disque
du noyau utilisée pour les fichiers de données de
PostgreSQL, bien que certaines données pourraient
être présentes aux deux endroits. Il faut également tenir
compte du nombre attendu de requêtes concurrentes sur des tables
différentes car elles partagent l'espace disponible. Ce paramètre n'a
pas d'influence sur la taille de la mémoire partagée allouée par
PostgreSQL, et ne réserve pas non plus le
cache disque du noyau ; il n'a qu'un rôle estimatif. Le système
ne suppose pas non plus que les données reste dans le cache du disque
entre des requêtes. Si cette valeur est indiquée sans unité, elle est
pris comme un nombre de blocs, autrement dit BLCKSZ
octets, typiquement 8 Ko. La valeur par défaut est de 4 Go
(4GB
). (Si BLCKSZ
n'est pas 8 Ko, les
valeurs par défaut changent de façon proportionnée.)
jit_above_cost
(floating point
)
Configure le coût de la requête au-dessus duquel la compilation JIT
est activée (voir Chapitre 31). Exécuter
JIT coûte en temps de planification mais peut
accélérer l'exécution de la requête. Configurer ce paramètre à
-1
désactive la compilation JIT. Le défaut est
100000
.
jit_inline_above_cost
(floating point
)
Configure le coût de requête au-dessus duquel la compilation JIT tente
de mettre à plat fonctions et opérateurs. Ceci ajoute au temps de
planification mais peut améliorer la durée d'exécution. Il n'y a pas
de sens à le configurer à une valeur inférieure à celle de
jit_above_cost
. Le configurer à
-1
désactive cette mise à plat. Le défaut est
500000
.
jit_optimize_above_cost
(floating point
)
Configure le coût de requête au-dessus duquel la compilation JIT
utilise aussi les optimisations coûteuses. De telles optimisations
ajoutent au temps de planification mais peuvent améliorer la durée
d'exécution. Il n'y a pas de sens à le configurer à une valeur
inférieure à celle de jit_above_cost
, et il y a peu
d'intérêt à le configurer à une valeur supérieure à
jit_inline_above_cost
. Le configurer à
-1
désactive ces optimisations. Le défaut est
500000
.
L'optimiseur génétique de requête (GEQO) est un algorithme qui fait la planification d'une requête en utilisant une recherche heuristique. Cela réduit le temps de planification pour les requêtes complexes (celles qui joignent de nombreuses relations), au prix de plans qui sont quelques fois inférieurs à ceux trouvés par un algorithme exhaustif. Pour plus d'informations, voir Chapitre 59.
geqo
(boolean
)
Active ou désactive l'optimisation génétique des requêtes. Activé par
défaut. Il est généralement préférable de ne pas le désactiver sur un
serveur en production. La variable geqo_threshold
fournit un moyen plus granulaire de désactiver le GEQO.
geqo_threshold
(integer
)
L'optimisation génétique des requêtes est utilisée pour planifier les
requêtes si, au minimum, ce nombre d'éléments est impliqué dans la clause
FROM
(une construction FULL OUTER JOIN
ne compte que pour un élément du FROM
). La valeur par
défaut est 12. Pour des requêtes plus simples, il est préférable d'utiliser
le planificateur standard, à recherche exhaustive. Par contre, pour les requêtes
avec un grand nombre de tables, la recherche exhaustive prend trop de temps,
souvent plus de temps que la pénalité à l'utilisation d'un plan non optimal.
Du coup, une limite sur la taille de la requête est un moyen simple de gérer
l'utilisation de GEQO.
geqo_effort
(integer
)Contrôle le compromis entre le temps de planification et l'efficacité du plan de requête dans GEQO. Cette variable est un entier entre 1 et 10. La valeur par défaut est de cinq. Des valeurs plus importantes augmentent le temps passé à la planification de la requête mais aussi la probabilité qu'un plan de requête efficace soit choisi.
geqo_effort
n'a pas d'action directe ;
il est simplement utilisé pour calculer les
valeurs par défaut des autres variables influençant le
comportement de GEQO (décrites ci-dessous). Il est également
possible de les configurer manuellement.
geqo_pool_size
(integer
)
Contrôle la taille de l'ensemble utilisé par GEQO. C'est-à-dire
le nombre d'individus au sein d'une population génétique. Elle
doit être au minimum égale à deux, les valeurs utiles étant
généralement comprises entre 100 et 1000. Si elle est configurée
à zéro (valeur par défaut), alors une valeur convenable est choisie
en fonction de geqo_effort
et du nombre de
tables dans la requête.
geqo_generations
(integer
)
Contrôle le nombre de générations utilisées par GEQO.
C'est-à-dire le nombre d'itérations de l'algorithme. Il doit être au
minimum de un, les valeurs utiles se situent dans la même plage que la
taille de l'ensemble. S'il est configuré à zéro (valeur par
défaut), alors une valeur convenable est choisie en fonction de
geqo_pool_size
.
geqo_selection_bias
(floating point
)Contrôle le biais de sélection utilisé par GEQO. C'est-à-dire la pression de sélectivité au sein de la population. Les valeurs s'étendent de 1.50 à 2.00 (valeur par défaut).
geqo_seed
(floating point
)Contrôle la valeur initiale du générateur de nombres aléatoires utilisé par GEQO pour sélectionner des chemins au hasard dans l'espace de recherche des ordres de jointures. La valeur peut aller de zéro (valeur par défaut) à un. Varier la valeur modifie l'ensemble des chemins de jointure explorés et peut résulter en des chemins meilleurs ou pires.
default_statistics_target
(integer
)
Initialise la cible de statistiques par défaut pour les colonnes de
table pour lesquelles aucune cible de colonne spécifique n'a été configurée via
ALTER TABLE SET STATISTICS
. Des valeurs élevées
accroissent le temps nécessaire à l'exécution
d'ANALYZE
mais peuvent permettre d'améliorer la
qualité des estimations du planificateur. La valeur par
défaut est 100. Pour plus d'informations sur l'utilisation des
statistiques par le planificateur de requêtes, se référer à la
Section 14.2.
constraint_exclusion
(enum
)
Contrôle l'utilisation par le planificateur de requête des contraintes
pour optimiser les requêtes.
Les valeurs autorisées de constraint_exclusion
sont
on
(examiner les contraintes pour toutes les tables),
off
(ne jamais examiner les contraintes) et
partition
(n'examiner les contraintes que pour les
tables enfants d'un héritage et pour les sous-requêtes UNION ALL
).
partition
est la valeur par défaut. C'est souvent
utilisé avec les tables héritées pour améliorer les performances.
Quand ce paramètre l'autorise pour une table particulière, le planificateur
compare les conditions de la requête avec les contraintes CHECK
sur la table, et omet le parcourt des tables pour lesquelles les
conditions contredisent les contraintes. Par exemple :
CREATE TABLE parent(clef integer, ...); CREATE TABLE fils1000(check (clef between 1000 and 1999)) INHERITS(parent); CREATE TABLE fils2000(check (clef between 2000 and 2999)) INHERITS(parent); ... SELECT * FROM parent WHERE clef = 2400;
Avec l'activation de l'exclusion par contraintes, ce SELECT
ne parcourt pas fils1000
, ce qui améliore les
performances.
À l'heure actuelle, l'exclusion de contraintes est activée par défaut seulement pour les cas souvent utilisés pour implémenter le partitionnement de tables via les arbres d'héritage. L'activer pour toutes les tables impose une surcharge de planification qui est visible pour de simples requêtes, sans apporter de bénéfices pour ces requêtes. Si vous n'avez pas de tables partitionnées utilisant l'héritage traditionnel, vous pourriez vouloir le désactiver. (Notez que la fonctionnalité équivalente pour les tables partitionnées est contrôlée par un paramètre séparé, enable_partition_pruning.)
Reportez vous à Section 5.11.5 pour plus d'informations sur l'utilisation d'exclusion de contraintes pour implémenter le partitionnement.
cursor_tuple_fraction
(floating point
)Positionne la fraction, estimée par le planificateur, d'enregistrements d'un curseur qui sera récupérée. La valeur par défaut est 0.1. Des valeurs plus petites de ce paramètre rendent le planificateur plus enclin à choisir des plans à démarrage rapide (« fast start »), qui récupèreront les premiers enregistrements rapidement, tout en mettant peut être un temps plus long à récupérer tous les enregistrements. Des valeurs plus grandes mettent l'accent sur le temps total estimé. À la valeur maximum 1.0 du paramètre, les curseurs sont planifiés exactement comme des requêtes classiques, en ne prenant en compte que le temps total estimé et non la vitesse à laquelle les premiers enregistrements seront fournis.
from_collapse_limit
(integer
)
Le planificateur assemble les sous-requêtes dans des requêtes
supérieures si la liste FROM
résultante contient
au plus ce nombre d'éléments. Des valeurs faibles réduisent le temps
de planification mais conduisent à des plans de requêtes inférieurs.
La valeur par défaut est de 8. Pour plus d'informations, voir Section 14.3.
Configurer cette valeur à geqo_threshold ou plus pourrait déclencher l'utilisation du planificateur GEQO, ce qui pourrait aboutir à la génération de plans non optimaux. Voir Section 19.7.3.
jit
(boolean
)
Détermine si la compilation JIT peut être utilisée
par PostgreSQL, quand elle est disponible
(voir Chapitre 31). La valeur par défaut est
on
.
join_collapse_limit
(integer
)
Le planificateur réécrit les constructions JOIN
explicites (à l'exception de FULL JOIN
) en une
liste d'éléments FROM
à chaque fois qu'il n'en
résulte qu'une liste ne contenant pas plus de ce nombre
d'éléments. Des valeurs faibles réduisent le temps de
planification mais conduisent à des plans de requêtes inférieurs.
Par défaut, cette variable a la même valeur que
from_collapse_limit
, valeur adaptée à la
plupart des utilisations. Configurer cette variable à 1
empêche le réordonnancement des JOIN
tures explicites.
De ce fait, l'ordre des jointures explicites indiqué dans la requête
est l'ordre réel dans lequel les relations
sont jointes. Le planificateur de la requête ne choisit pas toujours
l'ordre de jointure optimal ; les utilisateurs aguerris peuvent
choisir d'initialiser temporairement cette variable à 1 et
d'indiquer explicitement l'ordre de jointure souhaité.
Pour plus d'informations, voir Section 14.3.
Configurer cette valeur à geqo_threshold ou plus pourrait déclencher l'utilisation du planificateur GEQO, ce qui pourrait aboutir à la génération de plans non optimaux. Voir Section 19.7.3.
parallel_leader_participation
(boolean
)
Permet au processus « leader » d'exécuter le plan d'exécution
sous les nœuds Gather
et Gather Merge
, au lieu d'attendre les workers. Le défaut est
on
. Passer cette valeur à off
réduit la probabilité que les workers soient bloqués parce que le
processus leader ne lit pas les enregistrements assez vite, mais
nécessite que le processus leader attende que les workers démarrent
avant que le premier enregistrement ne soit produit. À quel point
le leader peut aider ou gêner la performance dépend du type de plan, du
nombre de workers et de la durée de la requête.
force_parallel_mode
(enum
)
Autorise l'utilisation de requêtes parallélisées pour des raisons de
test y compris dans des cas où aucune amélioration des performances
n'est attendue. Les valeurs autorisées de
force_parallel_mode
sont off
(utilise le mode parallèle seulement quand une amélioration des
performances est attendue), on
(force la
parallélisation de toutes les requêtes qui sont parallélisables) et
regress
(identique à on
, mais
avec un comportement supplémentaire expliqué ci-dessous).
Plus spécifiquement, configurer cette valeur à on
ajoutera un nœud Gather
au -dessus de tout plan
d'exécution pour lequel cela semble sain, permettant ainsi à la
requête d'être exécuté par un processus parallélisé. Même si un
processus parallélisé n'est pas disponible ou ne peut pas être
utilisé, les opérations, telles que le démarrage d'une sous-
transaction qui serait interdite dans un contexte de parallélisation
d'une requête, seront interdites sauf si le planificateur pense que
cela ferait échouer la requête. Si des échecs ou des résultats
inattendus surviennent avec cette option activée, certaines fonctions
utilisées par cette requête devraient être marquées PARALLEL
UNSAFE
(ou potentiellement PARALLEL
RESTRICTED
).
Configurer ce paramètre à regress
a les mêmes
effets que le configurer à on
avec quelques effets
supplémentaires ayant pour but de faciliter le test automatique de
régressions. Habituellement, les messages d'un processus parallèle
incluent une ligne de contexte le précisant, mais une configuration de
ce paramètre à la valeur regress
supprime cette
ligne pour que la sortie soit identique à une sortie pour une
exécution non parallélisée. De plus, les nœuds
Gather
ajoutés au plan par ce paramètre sont cachés
dans la sortie EXPLAIN
pour que la sortie
corresponde à ce qui serait obtenue si ce paramètre était désactivé
(valeur off
).
plan_cache_mode
(enum
)
Les requêtes préparées (soit explicitement préparées soit
implicitement générées, par exemple dans PL/pgSQL) peuvent être
exécutées en utilisant des plans personnalisés ou génériques. Les
plans personnalisés sont de nouveau créés à chaque exécution en
utilisant son ensemble spécifique de valeurs de paramètres, alors que
les plans génériques ne se basent pas sur les valeurs des paramètres
et peuvent être ré-utilisés au fil des exécutions. De ce fait,
l'utilisation d'un plan générique permet d'éviter de gâcher du temps
de planification mais si le plan idéal dépend fortement des valeurs de
paramètres, alors un plan générique pourrait être inefficace. Le choix
entre ces options est généralement fait automatiquement mais il peut
être forcé avec le paramètre plan_cache_mode
. Les
valeurs autorisées sont auto
(valeur par défaut),
force_custom_plan
et
force_generic_plan
. Ce paramètre est considéré
quand un plan en cache va être exécuté, et non pas quand il va être
préparé. Pour plus d'informations, voir PREPARE.