Type: enum
Défaut: partition
Contexte: user
Redémarrer: false
Valeurs: [partition, on, off]
indexterm>paramètre de configuration constraint_exclusion

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 à ddl-partitioning-constraint-exclusion pour plus d'informations sur l'utilisation d'exclusion de contraintes pour implémenter le partitionnement.

Recommandations [EN]

Default of “partition” is fine for most users. Setting it to “on” can allow optimization of UNION queries as well, but deserves testing before production deployment.

Commentaires