Ces paramètres de configuration fournissent une méthode dure 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 optimale, une solution temporaire pourrait être découverte en utilisant un de ces paramètres de configuration pour forcer l'optimiseur à choisir un meilleur plan. Désactiver un de ces paramétrages de façon permanente est néanmoins quelque fois une bonne idée. De meilleures façons d'améliorer la qualité des plans choisis par l'optimiseur incluent l'ajustement de Constantes de coût du planificateur , 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.
Active ou désactive l'utilisation des plans de parcours de bitmap par le planificateur de requêtes. Actif par défaut (on).
Active ou désactive l'utilisation des agrégats hachés par le planificateur. Actif par défaut.
Active ou désactive l'utilisation des jointures hachées par le planificateur. Actif par défaut.
Active ou désactive l'utilisation des parcours d'index par le planificateur. Actif par défaut.
Active ou désactive l'utilisation des jointures de fusion par le planificateur. Actif par défaut.
Active ou désactive l'utilisation des jointures de boucles imbriquées par le planificateur. Il n'est pas possible de supprimer les jointures de boucles imbriquées complètement mais désactiver cette variable décourage le planificateur de l'utiliser si d'autres méthodes sont disponibles. Actif par défaut.
Active ou désactive l'utilisation des parcours séquentiel par le planificateur. Il n'est pas possible de supprimer complètement les parcours séquentiels mais désactiver cette variable décourage le planificateur de l'utiliser si d'autres méthodes sont disponibles. Actif par défaut.
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 désactiver cette variable décourage le planificateur de l'utiliser si d'autres méthodes sont disponibles. Actif par défaut.
Active ou désactive l'utilisation des parcours de TID par le planificateur. Actif par défaut.
![[Note]](images/note.png)
Malheureusement, il n'existe pas de méthode bien définie pour déterminer les valeurs idéales pour la famille des variables de coût (« cost ») qui apparaissent ci-dessous. Vous êtes encouragés à expérimenter et à partager vos découvertes.
Configure l'idée du planificateur sur la taille réelle du cache disque disponible pour un simple parcours d'index. Ceci est factorisé en estimation du coût d'utilisation d'un index ; une valeur plus grande rend un parcours d'index plus probable, une valeur plus basse favorise le parcours séquentiel. Lors de la modification de ce paramètre, vous devez considérer les tampons partagés de PostgreSQL™ et la partie cache disque du noyau qui seront utilisés pour les fichiers de données de PostgreSQL™. De plus, prenez en compte le nombre attendu de requêtes concurrentes utilisant différents index car elles devront partager l'espace disponible. Ce paramètre n'a pas d'effet sur la taille de la mémoire partagée allouée par PostgreSQL™, pas plus qu'il ne réserve de cache disque du noyau ; c'est utilisé uniquement dans un but d'estimation. La valeur est mesurée en pages disque, qui sont normalement de 8192 octets chaque. La valeur par défaut est de 1000.
Initialise l'estimation du coût du planificateur pour une page disque récupérée de façon non séquentielle. C'est mesuré comme un multiple du coût de récupération d'une page séquentielle. Une valeur plus haute rend plus probable l'utilisation d'un parcours séquentiel, une valeur basse l'utilisation d'un parcours d'index. La valeur par défaut est quatre.
Initialise l'estimation du coût du planificateur pour le traitement de chaque ligne lors d'une requête. C'est mesuré comme une fraction du coût de la récupération séquentielle d'une page. La valeur par défaut est 0,01.
Initialise l'estimation du coût du planificateur pour le traitement de chaque ligne lors d'un parcours d'index. C'est mesuré comme une fraction du coût de la récupération séquentielle d'une page. La valeur par défaut est 0,001.
Initialise l'estimation du coût du planificateur de requêtes pour le traitement de chaque opérateur dans une clause WHERE. C'est mesuré comme une fraction du coût de récupération séquentielle d'une page. La valeur par défaut est 0,025.
Active ou désactive l'optimisation génétique des requêtes, algorithme tentant de faire de la planification de requêtes sans recherche exhaustive. Activé par défaut. La variable geqo_threshold fournit un moyen plus fin pour désactiver certaines classes de requêtes.
Utilise l'optimisation génétique des requêtes pour planifier les requêtes avec au moins ce nombre d'éléments impliqués dans la clause FROM (notez qu'une construction JOIN externe compte seulement comme un élément du FROM). La valeur par défaut est de 12. Pour des requêtes simples, il est généralement préférable d'utiliser le planificateur déterministe, exhaustif mais pour les requêtes comprenant beaucoup de tables, le planificateur déterministe prendrait trop de temps.
Contrôle l'équité entre le temps de planification et l'efficacité du plan de requête dans GEQO. Cette variable doit être un entier entre 1 et 10. La valeur par défaut est 5. Les valeurs plus importantes augmentent le temps passé pendant la planification de la requête mais augmentent aussi la possibilité qu'un plan de requête efficace soit choisi.
geqo_effort ne fait réellement rien directement ; c'est seulement utilisé pour calculer les valeurs par défaut des autres variables qui influencent le comportement de GEQO (décrit ci-dessous). Si vous préférez, vous pouvez configurer les autres paramètres manuellement.
Contrôle la taille de la queue utilisée par GEQO. Cette taille est le nombre d'individus dans une population génétique. Elle doit être d'au moins deux, et les valeurs utiles sont typiquement 100 et 1000. Si elle est configurée à zéro (la valeur par défaut), alors une valeur par défaut convenable est choisie suivant geqo_effort et le nombre de tables dans la requête.
Contrôle le nombre de générations utilisé par GEQO. Les générations spécifient le nombre d'itérations de l'algorithme. Il doit être au moins un, et les valeurs utiles sont dans la même échelle que la taille de la queue. S'il est configuré à zéro (la valeur par défaut), alors une version par défaut convenable est choisie suivant geqo_pool_size.
Contrôle le biais de sélection utilisé par GEQO. C'est une pression sélective à l'intérieur de la population. Les valeurs peuvent aller de 1,50 à 2,00 ; ce dernier est la valeur par défaut.
Initialise la cible par défaut des statistiques pour les colonnes de table qui n'ont pas une cible spécifique de colonne configurée via ALTER TABLE SET STATISTICS. Des valeurs plus importantes accroissent le temps nécessaire à exécuter ANALYZE mais pourrait améliorer les estimations du planificateurs. La valeur par défaut est de 10. Pour plus d'informations sur l'utilisation des statistiques par le planificateur de requêtes de PostgreSQL™, référez-vous à la Section 13.2, « Statistiques utilisées par le planificateur ».
Active ou désactive l'utilisation de la table des contraintes par le planificateur des requêtes pour optimiser les requêtes. Désactivé par défaut (off).
Quand ce paramètre est activé (on), le planificateur compare les conditions de la requête avec les contraintes CHECK de la table et omet de parcourir les tables dont les conditions sont en contradiction avec les contraintes (actuellement, ceci se fait seulement pour les tables filles des parcours d'héritage). 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 key = 2400;
Avec l'activation de l'exclusion de la contrainte, ce SELECT ne parcourira pas du tout fils1000. Ceci peut améliorer les performances quand l'héritage est utilisé pour construire des tables partitionnées.
Actuellement, constraint_exclusion est désactivé par défaut (off) car il existe un risque de résultats incorrects si les plans de requêtes sont en cache -- si une contrainte de table est modifiée ou supprimée, le plan généré précédemment pourrait être faux maintenant et il n'existe pas de mécanisme intégré pour forcer une nouvelle planification (ce problème sera probablement résolu dans une prochaine version de PostgreSQL™). Une autre raison pour la conserver désactivée est que les vérifications de contraintes sont relativement coûteuses et, dans de nombreuses circonstances, ne font pas gagner de temps. Il est recommandé de l'activer seulement si vous utilisez réellement des tables partitionées conçues pour prendre tout l'avantage de cette fonctionnalité.
Référez-vous à la Section 5.9, « Partitionnement » pour plus d'informations sur l'utilisation des exclusion de contraintes et du partitionement.
Le planificateur assemblera les sous-requêtes dans des requêtes supérieures si la liste FROM résultante n'aurait pas plus de ce nombre d'éléments. Des valeurs plus petites réduisent le temps de planification mais ramènent des plans de requêtes inférieurs. La valeur par défaut est huit. Il est généralement conseillé de conserver cette valeur inférieure à geqo_threshold.
Le planificateur réécrira les constructions JOIN internes explicites en listes d'éléments FROM à chaque fois qu'une liste d'au plus ce nombre d'éléments au total en résulterait. Avant PostgreSQL™ 7.4, les jointures spécifiées via la construction JOIN ne seraient jamais réordonnées. Le planificateur de la requête a du coup été amélioré pour que les jointures internes écrites de cette forme puissent être ré-ordonnées ; ce paramètre de configuration contrôle à quel point ce ré-ordonnancement sera réalisé.
À présent, l'ordre des jointures externes spécifiée via la construction JOIN n'est jamais ajusté par le planificateur de requêtes ; du coup, join_collapse_limit n'a aucun effet sur ce comportement. Le planificateur pourrait être amélioré pour ré-ordonner certaines classes de jointures externes dans une prochaine version de PostgreSQL™.
Par défaut, cette variable est configurée de la même façon que from_collapse_limit, qui est approprié pour la plupart des utilisations. Configurer cette variable à 1 empêche le réordonnancement des JOINtures internes. Du coup, l'ordre de jointure explicite spécifiée dans la requête sera 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 avancées pourraient choisir d'initialiser temporairement cette variable à 1, puis de spécifier l'ordre de jointure qu'ils désirent explicitement. Une autre conséquence en l'initialisant à 1 est que le planificateur de requêtes se comporte plus comme le planificateur de requête de PostgreSQL™ 7.3, ce que certains utilisateurs trouvent utile pour des raisons de compatibilités descendantes.
Configurer cette variable à une valeur entre 1 et from_collapse_limit pourrait être utile pour négocier entre le temps de planification et la qualité du plan choisie (les grandes valeurs produisent les meilleures plans).
Write Ahead Log