Paramètres de serveur Azure Cosmos DB for PostgreSQL

S’APPLIQUE À : Azure Cosmos DB for PostgreSQL (avec l’extension de base de données Citus pour PostgreSQL)

Il existe différents paramètres de serveur qui affectent le comportement d’Azure Cosmos DB pour PostgreSQL, à la fois à partir de PostgreSQL standard et spécifiques à Azure Cosmos DB pour PostgreSQL. Ces paramètres peuvent être définis sur le portail Azure pour un cluster. Sous la catégorie Paramètres, choisissez les paramètres du Nœud worker ou du Nœud coordinateur. Ces pages vous permettent de définir des paramètres pour tous les nœuds Worker, ou uniquement pour le nœud coordinateur.

Paramètres Azure Cosmos DB for PostgreSQL

Configuration générale

citus.use_secondary_nodes (énumération)

Définit la stratégie à utiliser lors du choix des nœuds pour les requêtes SELECT. S’il est défini sur « always », le planificateur interroge uniquement les nœuds marqués en tant que noderole « secondaires » dans pg_dist_node.

Les valeurs prises en charge pour cette énumération sont les suivantes :

• jamais : (par défaut) toutes les lectures se produisent sur les nœuds principaux.
• always : Les lectures sont exécutées sur les nœuds secondaires à la place et les commandes insert/update sont désactivées.

citus.cluster_name (texte)

Informe le responsable du nœud coordinateur du cluster qu’il coordonne. Une fois cluster_name défini, le planificateur interroge seulement les nœuds Worker dans ce cluster.

citus.enable_version_checks (booléen)

Mettre à niveau la version d’Azure Cosmos DB for PostgreSQL nécessite un redémarrage serveur (pour récupérer la nouvelle bibliothèque partagée), suivie de la commande ALTER EXTENSION UPDATE. L’échec de l’exécution des deux étapes peut entraîner des erreurs ou des blocages. Azure Cosmos DB for PostgreSQL valide donc la correspondance de la version du code et celle de l’extension, et retourne une erreur si elles ne correspondent pas.

Cette valeur est définie par défaut sur true et est effective sur le coordinateur. Dans de rares cas, les processus de mise à niveau complexes pourraient nécessiter l’affectation de la valeur false à ce paramètre, ce qui désactive la vérification.

citus.log_distributed_deadlock_detection (booléen)

Indique s’il faut enregistrer le traitement lié à la détection de blocage distribué dans le journal du serveur. La valeur par défaut est « False ».

citus.distributed_deadlock_detection_factor (virgule flottante)

Définit le délai d’attente avant de vérifier les blocages distribués. En particulier, le délai d’attente est cette valeur multipliée par le paramètre deadlock_timeout de PostgreSQL. La valeur par défaut est 2. Une valeur de -1 désactive la détection de blocage distribué.

citus.node_connection_timeout (entier)

Le GUC citus.node_connection_timeout définit la durée maximale (en millisecondes) d’attente de l’établissement de la connexion. Azure Cosmos DB for PostgreSQL génère une erreur si le délai d’attente s’écoule avant qu’au moins une connexion Worker soit établie. Ce GUC affecte les connexions entre le coordinateur et les workers, ainsi qu’entre les workers.

• Par défaut : cinq secondes
• Minimum : 10 millisecondes
• Maximum : une heure

-- set to 30 seconds
ALTER DATABASE foo
SET citus.node_connection_timeout = 30000;

citus.log_remote_commands (booléen)

Journaliser toutes les commandes que le coordinateur envoie aux nœuds Worker. Exemple :

-- reveal the per-shard queries behind the scenes
SET citus.log_remote_commands TO on;

-- run a query on distributed table "github_users"
SELECT count(*) FROM github_users;

La sortie révèle plusieurs requêtes exécutées sur les Workers en raison de la requête count(*) unique sur le coordinateur.

NOTICE:  issuing SELECT count(*) AS count FROM public.github_events_102040 github_events WHERE true
DETAIL:  on server citus@private-c.demo.postgres.database.azure.com:5432 connectionId: 1
NOTICE:  issuing SELECT count(*) AS count FROM public.github_events_102041 github_events WHERE true
DETAIL:  on server citus@private-c.demo.postgres.database.azure.com:5432 connectionId: 1
NOTICE:  issuing SELECT count(*) AS count FROM public.github_events_102042 github_events WHERE true
DETAIL:  on server citus@private-c.demo.postgres.database.azure.com:5432 connectionId: 1
... etc, one for each of the 32 shards

citus.show_shards_for_app_name_prefixes (text)

Par défaut, Azure Cosmos DB for PostgreSQL masque les partitions de la liste des tables que PostgreSQL donne aux clients SQL. Cela est dû au fait qu’il existe plusieurs partitions par table distribuée et que les partitions peuvent être détournées du client SQL.

Le GUC citus.show_shards_for_app_name_prefixes permet aux partitions d’être affichées pour les clients sélectionnés qui souhaitent les voir. Sa valeur par défaut est  ».

-- show shards to psql only (hide in other clients, like pgAdmin)

SET citus.show_shards_for_app_name_prefixes TO 'psql';

-- also accepts a comma separated list

SET citus.show_shards_for_app_name_prefixes TO 'psql,pg_dump';

Le masquage de partitions peut être désactivé entièrement à l’aide de citus.override_table_visibility.

citus.override_table_visibility (booléen)

Détermine si citus.show_shards_for_app_name_prefixes est actif. La valeur par défaut est « true ». Lorsque la valeur est « false », les partitions sont visibles pour toutes les applications clientes.

citus.use_citus_managed_tables (booléen)

Autoriser les nouvelles tables locales à accéder aux requêtes sur les nœuds Worker. Ajoute toutes les tables nouvellement créées aux métadonnées Citus lorsqu’elles sont activées. La valeur par défaut est « false ».

citus.rebalancer_by_disk_size_base_cost (entier)

Avec la stratégie de rééquilibrage by_disk_size, chaque groupe de partitions voit ce coût en octets s’ajouter à celui de sa taille de disque réelle. Cette valeur est utilisée pour éviter de créer un mauvais équilibre lorsqu’il y a peu de données dans certaines des partitions. L’hypothèse est que même les partitions vides ont un certain coût, en raison du parallélisme et parce que les groupes de partitions vides sont susceptibles de croître à l’avenir.

La valeur par défaut est 100MB.

Statistiques sur les requêtes

citus.stat_statements_purge_interval (entier)

Définit la fréquence à laquelle le démon de maintenance supprime les enregistrements de citus_stat_statements qui n’ont pas de correspondance pas dans pg_stat_statements. Cette valeur de configuration définit l’intervalle de temps entre les suppressions, en secondes, avec une valeur par défaut de 10. La valeur 0 désactive les suppressions.

SET citus.stat_statements_purge_interval TO 5;

Ce paramètre est effectif sur le coordinateur et peut être modifié au moment de l’exécution.

citus.stat_statements_max (entier)

Nombre maximal de lignes à stocker dans citus_stat_statements. La valeur par défaut (50 000) peut être modifiée sur n’importe quelle valeur comprise dans la plage 1 000 et 10 000 000. Chaque ligne requiert 140 octets de stockage, donc si le paramètre stat_statements_max est défini sur la valeur maximale (10M), 1,4 Go de mémoire sera consommé.

La modification de ce GUC ne prend effet qu’à partir du redémarrage de PostgreSQL.

citus.stat_statements_track (énumération)

L’enregistrement des statistiques pour citus_stat_statements requiert des ressources processeur supplémentaires. Quand la base de données gère une charge importante, l’administrateur peut désactiver le suivi des instructions en définissant citus.stat_statements_track sur none.

• all : (valeur par défaut) suit toutes les instructions.
• none : désactiver le suivi.

citus.stat_tenants_untracked_sample_rate

Taux d’échantillonnage pour les nouveaux locataires dans citus_stat_tenants. Le taux peut être compris entre 0.0 et 1.0. La valeur par défaut 1.0 signifie que 100 % des requêtes de locataires non suivies sont échantillonnées. La définition d’une valeur inférieure signifie que les locataires déjà suivis ont des requêtes échantillonnées de 100 %, mais que les locataires actuellement non suivis ne sont échantillonnés qu’au taux fourni.

Chargement des données

citus.multi_shard_commit_protocol (énumération)

Définit le protocole de validation à utiliser lors de l’exécution d’une copie sur une table distribuée de hachage. À chaque sélection élective de partition individuelle, la commande COPY est effectuée dans un bloc de transaction pour garantir qu’aucune donnée n’est ingérée si une erreur se produit pendant la copie. Toutefois, il existe un cas de défaillance particulier dans lequel la commande COPY est réussie sur toutes les sélections électives, mais une défaillance (matérielle) se produit avant la validation de toutes les transactions. Ce paramètre peut être utilisé pour éviter la perte de données dans ce cas en choisissant entre les protocoles de validation suivants :

• 2pc : (par défaut) Les transactions dans lesquelles l’opération COPY est effectuée sur les placements de partitions sont d’abord préparées en utilisant un une validation en deux phases de PostgreSQL, puis elles sont validées. Les validations ayant échoué peuvent être récupérées ou annulées manuellement à l’aide de COMMIT PREPARED ou ROLLBACK PREPARED, respectivement. Lors de l’utilisation de 2pc, max_prepared_transactions doit être augmenté sur tous les Workers, généralement sur à la même valeur que max_connections.
• 1pc : Les transactions dans lesquelles la commande COPY est effectuée sur les sélections électives de partition sont validées en une seule fois. Les données peuvent être perdues si une validation échoue après la fin de la copie sur toutes les sélections électives (cas rare).

citus.shard_replication_factor (entier)

Définit le facteur de réplication pour partitions, c’est-à-dire le nombre de nœuds sur lesquels les partitions sont placées, et la valeur par défaut est 1. Ce paramètre peut être défini au moment de l’exécution et est effectif sur le coordinateur. La valeur idéale pour ce paramètre dépend de la taille du cluster et du taux d’échec du nœud. Par exemple, vous souhaitez augmenter ce facteur de réplication si vous exécutez des clusters de grande taille et observez les défaillances de nœuds plus fréquemment.

Configuration du planificateur

citus.local_table_join_policy (énumération)

Ce GUC détermine comment Azure Cosmos DB for PostgreSQL déplace les données lors de l’établissement d’une jointure entre des tables locales et distribuées. La personnalisation de la stratégie de jointure peut aider à réduire la quantité de données envoyées entre les nœuds Worker.

Si nécessaire, Azure Cosmos DB for PostgreSQL envoie les tables locales ou distribuées aux nœuds pour prendre en charge la jointure. La copie de données de table est appelée « conversion ». Si une table locale est convertie, elle est envoyée aux Workers qui ont besoin de ses données pour effectuer la jointure. Si une table distribuée est convertie, elle est collectée dans le coordinateur pour prendre en charge la jointure. Le planificateur Azure Cosmos DB for PostgreSQL envoie uniquement les lignes nécessaires effectuant une conversion.

Quatre modes permettent d’exprimer la préférence de conversion :

• auto : (par défaut) Azure Cosmos DB for PostgreSQL convertit toutes les tables locales ou toutes les tables distribuées pour prendre en charge les jointures de tables locales et distribuées. Azure Cosmos DB pour PostgreSQL décide de convertir à l’aide d’une heuristique. Il convertit les tables distribuées si elles sont jointes à l’aide d’un filtre constant sur un index unique (par exemple, une clé primaire). La conversion garantit que moins de données sont déplacées entre les Workers.
• jamais : Azure Cosmos DB for PostgreSQL n’autorise pas les jointures entre les tables locales et distribuées.
• prefer-local : Azure Cosmos DB for PostgreSQL préfère convertir les tables locales pour prendre en charge les jointures de tables locales et distribuées.
• prefer-distributed : Azure Cosmos DB for PostgreSQL préfère convertir les tables distribuées pour prendre en charge les jointures de tables locales et distribuées. Si les tables distribuées sont volumineuses, l’utilisation de cette option peut entraîner le déplacement d’un grand nombre de données entre les Workers.

Par exemple, supposons que citus_table est une table distribuée par la colonne x et que postgres_table est une table locale :

CREATE TABLE citus_table(x int primary key, y int);
SELECT create_distributed_table('citus_table', 'x');

CREATE TABLE postgres_table(x int, y int);

-- even though the join is on primary key, there isn't a constant filter
-- hence postgres_table will be sent to worker nodes to support the join
SELECT * FROM citus_table JOIN postgres_table USING (x);

-- there is a constant filter on a primary key, hence the filtered row
-- from the distributed table will be pulled to coordinator to support the join
SELECT * FROM citus_table JOIN postgres_table USING (x) WHERE citus_table.x = 10;

SET citus.local_table_join_policy to 'prefer-distributed';
-- since we prefer distributed tables, citus_table will be pulled to coordinator
-- to support the join. Note that citus_table can be huge.
SELECT * FROM citus_table JOIN postgres_table USING (x);

SET citus.local_table_join_policy to 'prefer-local';
-- even though there is a constant filter on primary key for citus_table
-- postgres_table will be sent to necessary workers because we are using 'prefer-local'.
SELECT * FROM citus_table JOIN postgres_table USING (x) WHERE citus_table.x = 10;

citus.limit_clause_row_fetch_count (entier)

Définit le nombre de lignes à extraire par tâche pour l’optimisation de la clause LIMIT. Dans certains cas, certaines requêtes avec des clauses de limitation pourraient avoir besoin d’extraire toutes les lignes de chaque tâche pour générer des résultats. Dans ces cas-là, et lorsqu’une approximation produirait des résultats significatifs, cette valeur de configuration définit le nombre de lignes à extraire à partir de chaque partition. Les approximations de limites sont désactivées par défaut et ce paramètre est définit sur -1. Cette valeur peut être définie au moment de l’exécution et est effective sur le coordinateur.

citus.count_distinct_error_rate (virgule flottante)

Azure Cosmos DB for PostgreSQL peut calculer le nombre count(distinct) approximatif à l’aide de l’extension postgresql-hll. Cette entrée de configuration définit le taux d’erreur souhaité lors du calcul du count(distinct). 0,0, qui est la valeur par défaut, désactive les approximations pour count(distinct); et 1,0 ne fournit aucune garantie quant à l’exactitude des résultats. Nous vous recommandons de définir ce paramètre sur 0,005 pour obtenir de meilleurs résultats. Cette valeur peut être définie au moment de l’exécution et est effective sur le coordinateur.

citus.task_assignment_policy (énumération)

Définit la stratégie à utiliser lors de l’affectation de tâches aux workers. Le coordinateur affecte des tâches aux workers en fonction des emplacements de partition. Cette valeur de configuration spécifie la stratégie à utiliser lors de ces affectations. Actuellement, il existe trois stratégies d’attribution de tâches possibles qui peuvent être utilisées.

• greedy : La stratégie greedy est la stratégie par défaut et vise à répartir uniformément les tâches entre les workers.
• round-robin : La stratégie round-robin attribue des tâches aux workers dans un mode round robin alternant entre les différents réplicas. Cette stratégie permet une meilleure utilisation du cluster lorsque le nombre de partitions pour une table est faible par rapport au nombre de workers.
• first-replica : la stratégie first-replica assigne des tâches en fonction de l’ordre d’insertion des placements (réplicas) pour les partitions. En d’autres termes, la requête de fragment pour une partition est assignée au worker qui a le premier réplica de cette partition. Cette méthode vous permet d’avoir des garanties fortes quant à quelles partitions seront utilisées sur quels nœuds (autrement dit, de plus fortes garanties de fichiers restant en mémoire).

Ce paramètre peut être défini au moment de l’exécution et est effectif sur le coordinateur.

citus.enable_non_colocated_router_query_pushdown (booléen)

Active le planificateur de routeurs pour les requêtes qui référencent des tables distribuées non colocalisées.

Le planificateur de routeurs est activé uniquement pour les requêtes qui référencent des tables distribuées colocalisées, car, dans le cas contraire, les partitions peuvent ne pas se trouver sur le même nœud. L’activation de cet indicateur permet d’optimiser les requêtes qui référencent ces tables, mais la requête pourrait ne pas fonctionner après le rééquilibrage des partitions ou la modification du nombre de partitions de ces tables.

Par défaut, il s’agit de off.

Transfert des données intermédiaires

citus.max_intermediate_result_size (entier)

Taille maximale, en Ko, des résultats intermédiaires pour les expressions de table commune qui ne peuvent pas être transférées vers les nœuds Worker pour exécution, et pour les sous-requêtes complexes. La valeur par défaut est 1 Go et la valeur -1 signifie aucune limite. Les requêtes qui dépassent la limite sont annulées et génèrent un message d’erreur.

DDL

citus.enable_schema_based_sharding

La définition du paramètre sur ON entraîne la distribution par défaut de tous les schémas créés. Les schémas distribués sont automatiquement associés à des groupes de colocation individuels, de sorte que les tables créées dans ces schémas sont converties en tables distribuées colocalisées sans clé de partition. Ce paramètre peut être modifié pour des sessions individuelles.

Pour obtenir un exemple d’utilisation de ce GUC, consultez Comment concevoir pour les microservices.

Configuration de l’exécuteur

Général

citus.all_modifications_commutative

Azure Cosmos DB for PostgreSQL applique les règles de commutativité et acquiert les verrous appropriés pour les opérations de modification afin de garantir l’exactitude du comportement. Par exemple, il suppose qu’une instruction INSERT est commutative avec une autre instruction INSERT, mais pas avec une instruction UPDATE ou DELETE. De même, il suppose qu’une instruction UPDATE ou DELETE ne commute pas avec une autre instruction UPDATE ou DELETE. Cette précaution signifie que les mises à jour et les suppressions nécessitent que Azure Cosmos DB for PostgreSQL acquiert des verrous plus forts.

Si vous avez des instructions UPDATE qui sont commutatives avec vos INSERT ou d’autres UPDATE, vous pouvez assouplir ces hypothèses de commutativité en affectant à ce paramètre la valeur true. Lorsque ce paramètre est défini sur true, toutes les commandes sont considérées comme commutatives et revendiquent un verrou partagé, ce qui peut améliorer le débit global. Ce paramètre peut être défini au moment de l’exécution et est effectif sur le coordinateur.

citus.remote_task_check_interval (entier)

Définit la fréquence à laquelle Azure Cosmos DB for PostgreSQL vérifie les états des tâches gérés par l’exécuteur de suivi de tâches. La valeur par défaut est 10 ms. Le coordinateur attribue des tâches aux Workers, puis vérifie régulièrement auprès de ceux-ci la progression de chaque tâche. Cette valeur de configuration définit l’intervalle de temps entre deux contrôles. Ce paramètre est effectif sur le coordinateur et peut être défini au moment de l’exécution.

citus.task_executor_type (énumération)

Azure Cosmos DB for PostgreSQL a trois types d’exécuteur pour l’exécution de requêtes SELECT distribuées. L’exécuteur souhaité peut être sélectionné en définissant ce paramètre de configuration. Les valeurs acceptables pour ce paramètre sont :

• adaptive : Valeur par défaut. Elle est optimale pour les réponses rapides aux requêtes qui impliquent des agrégations et des jointures en colocation s’étendant sur plusieurs partitions.
• task-tracker : L’exécuteur de suivi des tâches est adapté aux requêtes durables et complexes qui nécessitent une réutilisation aléatoire des données sur les nœuds Worker et une gestion efficace des ressources.
• real-time : (déconseillé) A un objectif similaire à celui de l’exécuteur adaptatif, mais il est moins flexible et peut entraîner une plus grande sollicitation des connexions sur les nœuds Worker.

Ce paramètre peut être défini au moment de l’exécution et est effectif sur le coordinateur.

citus.multi_task_query_log_level (énumération) {#multi_task_logging}

Définit un niveau de journal pour toute requête qui génère plus d’une tâche (c’est-à-dire, qui atteint plusieurs partitions). La journalisation est utile lors d’une migration d’applications multilocataire, car vous pouvez choisir d’émettre des erreurs ou des avertissements pour de telles requêtes, de les trouver et d’y ajouter un filtre id_locataire. Ce paramètre peut être défini au moment de l’exécution et est effectif sur le coordinateur. La valeur par défaut de ce paramètre est « off ».

Les valeurs prises en charge pour cette enum sont les suivantes :

• off : Désactivez la journalisation des requêtes qui génèrent plusieurs tâches (autrement dit, s’étendent sur plusieurs partitions)
• debug : Journalise l’instruction au niveau de gravité DEBUG.
• log : Journalise l’instruction au niveau de gravité LOG. La ligne de journal comprend la requête SQL qui a été exécutée.
• notice : Journalise l’instruction au niveau de gravité NOTICE.
• warning : Journalise l’instruction au niveau de gravité WARNING.
• error : Journalise l’instruction au niveau de gravité ERROR.

Il peut être utile d’utiliser error lors des tests de développement, ainsi qu’un niveau de journalisation plus bas comme log au cours du déploiement en production proprement dit. Si vous choisissez log , les requêtes multitâches apparaitront dans les journaux de base de données avec la requête elle-même, figurant après « STATEMENT ».

LOG:  multi-task query about to be executed
HINT:  Queries are split to multiple tasks if they have to be split into several queries on the workers.
STATEMENT:  select * from foo;

citus.propagate_set_commands (énumération)

Détermine les commandes SET qui sont propagées du coordinateur vers les Workers. La valeur par défaut de ce paramètre est « none ».

Les valeurs prises en charge sont les suivantes :

• none : aucune commande SET n’est propagée.
• local : seules les commandes SET LOCAL sont propagées.

citus.create_object_propagation (enum)

Contrôle le comportement des instructions CREATE dans les transactions pour les objets pris en charge.

Lorsque des objets sont créés dans un bloc de transaction multi-instruction, Azure Cosmos DB for PostgreSQL bascule le mode séquentiel pour garantir que les objets créés sont visibles par des instructions ultérieures sur des partitions. Toutefois, le commutateur en mode séquentiel n’est pas toujours souhaitable. En remplaçant ce comportement, l’utilisateur peut échanger les performances pour une cohérence transactionnelle complète lors de la création d’objets.

La valeur par défaut de ce paramètre est « immediate ».

Les valeurs prises en charge sont les suivantes :

• immédiat : déclenche une erreur dans les transactions où des opérations parallèles telles que create_distributed_table se produisent avant une tentative de TYPE CREATE.
• automatique : différer la création de types lors du partage d’une transaction avec une opération parallèle sur des tables distribuées. Il pourrait y avoir des incohérences entre les objets de base de données qui existent sur différents nœuds.
• différé : revenez au comportement antérieur à 11.0, ce qui est comme automatique, mais avec d’autres cas de coin subtils. Nous recommandons le paramètre automatique sur différé, sauf si vous avez besoin d’une compatibilité descendante vraie.

Pour obtenir un exemple de ce GUC en action, consultez la propagation de type.

citus.enable_repartition_joins (booléen)

En règle générale, la tentative d’exécution de jointures de répartition avec l’exécuteur adaptatif échoue avec un message d’erreur. Toutefois, l’affectation de la valeur true à citus.enable_repartition_joins permet à Azure Cosmos DB for PostgreSQL de basculer temporairement dans l’exécuteur de suivi des tâches pour effectuer la jointure. La valeur par défaut est false.

citus.enable_repartitioned_insert_select (booléen)

Par défaut, une instruction INSERT INTO... L’instruction SELECT qui ne peut pas être transférée tente de repartitionner les lignes à partir de l’instruction SELECT et de les transférer entre les Workers pour insertion. Toutefois, si la table cible présente trop de partitions, il est probable que le repartitionnement ne fonctionnera pas correctement. La surcharge liée au traitement des intervalles de partition en vue de déterminer les modalités de partitionnement des résultats est trop importante. Le repartitionnement peut être désactivé manuellement en définissant citus.enable_repartitioned_insert_select sur false.

citus.enable_binary_protocol (booléen)

Si ce paramètre a la valeur true, le nœud coordinateur utilise le format de sérialisation binaire PostgreSQL (le cas échéant) pour transférer des données avec les Workers. Certains types de colonnes ne prennent pas en charge la sérialisation binaire.

L’activation de ce paramètre est surtout utile lorsque les Workers doivent retourner de grandes quantités de données. Par exemple, lorsque de nombreuses lignes sont demandées, les lignes présentent de nombreuses colonnes ou utilisent des types larges tels que hll à partir de l’extension postgresql-hll.

La valeur par défaut est true. Lorsque la valeur est définie sur false, tous les résultats sont encodés et transférés au format texte.

citus.max_adaptive_executor_pool_size (entier)

Max_adaptive_executor_pool_size limite les connexions de travail à partir de la session active. Ce GUC est utile pour :

• empêcher un seul back-end d’obtenir toutes les ressources Worker ;
• gérer les priorités : désigner les sessions à faible priorité présentant une valeur max_adaptive_executor_pool_size faible et les sessions à priorité élevée présentant des valeurs plus élevées.

La valeur par défaut est 16.

citus.executor_slow_start_interval (entier)

Délai d’attente en millisecondes entre les connexions ouvertes sur le même nœud Worker.

Lorsque les tâches individuelles d’une requête sur plusieurs partitions prennent peu de temps, elles peuvent souvent se terminer sur une connexion unique (souvent déjà mise en cache). Pour éviter d’ouvrir de manière redondante d’autres connexions, l’exécuteur attend entre les tentatives de connexion le nombre de millisecondes configuré. À la fin de l’intervalle, il augmente le nombre de connexions qu’il est autorisé à ouvrir la prochaine fois.

Pour les requêtes longues (qui prennent >500 ms), le démarrage lent peut augmenter la latence, mais pour les requêtes courtes, le démarrage est plus rapide. La valeur par défaut est de 10 ms.

citus.max_cached_conns_per_worker (entier)

Chaque back-end ouvre des connexions aux Workers pour interroger les partitions. À la fin de la transaction, le nombre configuré de connexions est maintenu ouvert pour accélérer les commandes suivantes. L’augmentation de cette valeur réduit la latence des requêtes multipartitions, mais augmente la surcharge sur les Workers.

La valeur par défaut est 1. Une valeur plus élevée (par exemple, 2) peut être utile pour les clusters qui utilisent un petit nombre de sessions simultanées, mais il n’est pas judicieux d’aller plus loin (par exemple, 16 est trop élevé).

citus.force_max_query_parallelization (booléen)

Simule l’exécuteur en temps réel abandonné et désormais inexistant. Ce paramètre permet d’ouvrir le plus grand nombre de connexions possibles pour optimiser la parallélisation des requêtes.

Lorsque cette GUC est activée, Azure Cosmos DB for PostgreSQL force l’exécuteur adaptatif à utiliser autant de connexions que possible lors de l’exécution d’une requête distribuée parallèle. Si ce paramètre n’est pas activé, l’exécuteur peut choisir d’utiliser moins de connexions pour optimiser le débit global d’exécution des requêtes. En interne, la définition de ce paramètre sur true entraîne l’utilisation d’une connexion par tâche.

Ce paramètre est utile dans une transaction dont la première requête est légère et nécessite peu de connexions, tandis qu’une requête ultérieure pourrait bénéficier de connexions supplémentaires. Azure Cosmos DB for PostgreSQL détermine le nombre de connexions à utiliser dans une transaction basée sur la première instruction, ce qui peut limiter les autres requêtes, sauf si nous utilisons le GUC pour fournir un conseil.

BEGIN;
-- add this hint
SET citus.force_max_query_parallelization TO ON;

-- a lightweight query that doesn't require many connections
SELECT count(*) FROM table WHERE filter = x;

-- a query that benefits from more connections, and can obtain
-- them since we forced max parallelization above
SELECT ... very .. complex .. SQL;
COMMIT;

La valeur par défaut est false.

Configuration de l’exécuteur du suivi des tâches

citus.task_tracker_delay (entier)

Ce paramètre définit la durée de veille du suivi des tâches entre les phases de gestion des tâches et la valeur par défaut de 200 ms. Le processus du suivi des tâches se réveille régulièrement, passe en revue toutes les tâches qui lui sont affectées et planifie et exécute ces tâches. Ensuite, le suivi des tâches se met en veille pendant une période de temps avant de parcourir ces tâches à nouveau. Cette valeur de configuration détermine la durée de cette période de sommeil. Ce paramètre est effectif sur les Workers et doit être modifié dans le fichier PostgreSQL. conf. Après avoir modifié le fichier de configuration, les utilisateurs peuvent envoyer un signal SIGHUP ou redémarrer le serveur pour que cette modification prenne effet.

Ce paramètre peut être réduit pour diminuer le délai dû à l’exécuteur du suivi des tâches en réduisant l’intervalle de temps entre les phases de gestion. La diminution du délai est utile dans les cas où les requêtes de partition sont courtes et, par conséquent, mettent régulièrement à jour leur état.

citus.max_assign_task_batch_size (entier)

L’exécuteur du suivi des tâches sur le coordinateur assigne de façon synchrone des tâches par lots au démon sur les Workers. Ce paramètre définit le nombre maximal de tâches à assigner dans un lot unique. Le choix d’une taille de lot plus importante permet une attribution plus rapide des tâches. Toutefois, si le nombre de Workers est élevé, l’obtention de tâches par tous les Workers peut prendre plus de temps. Ce paramètre peut être défini au moment de l’exécution et est effectif sur le coordinateur.

citus.max_running_tasks_per_node (entier)

Le processus du suivi des tâches planifie et exécute les tâches qui lui sont assignées, le cas échéant. Cette valeur de configuration définit le nombre maximal de tâches à exécuter simultanément sur un nœud à tout moment donné et la valeur par défaut est 8.

La limite vous permet de ne pas avoir de nombreuses tâches impactant le disque en même temps et d’éviter la contention des E/S disque. Si vos requêtes sont traitées à partir de la mémoire ou de disques SSD, vous pouvez augmenter max_running_tasks_per_node sans grand problème.

citus.partition_buffer_size (entier)

Définit la taille de la mémoire tampon à utiliser pour les opérations de partition et la valeur par défaut est de 8 Mo. Azure Cosmos DB for PostgreSQL permet de repartitionner les données de table en plusieurs fichiers lorsque deux tables volumineuses sont jointes. Une fois cette mémoire tampon remplie, les données de nouveau partitionnées sont vidées dans des fichiers sur le disque. Cette entrée de configuration peut être définie au moment de l’exécution et est effective sur les Workers.

Sortie explain

citus.explain_all_tasks (booléen)

Par défaut, Azure Cosmos DB for PostgreSQL affiche le résultat d’une tâche arbitraire unique lors de l’exécution d’EXPLAIN sur une requête distribuée. Dans la plupart des cas, le résultat « explain » sera similaire entre les tâches. Il arrive que certaines tâches soient planifiées différemment ou aient des durées d’exécution bien supérieures. Dans ces cas, il peut être utile d’activer ce paramètre, après quoi le résultat EXPLAIN inclura toutes les tâches. L’explication de toutes les tâches pourrait rallonger le délai pour EXPLAIN.

citus.explain_analyze_sort_method (énumération)

Détermine la méthode de tri des tâches dans la sortie de EXPLAIN ANALYZE. La valeur par défaut de citus.explain_analyze_sort_method est execution-time.

Les valeurs prises en charge sont les suivantes :

• execution-time : trier par heure d’exécution.
• taskId : trier par ID de tâche.

Paramètres PgBouncer managé

Les paramètres PgBouncer managé suivants peuvent être configurés sur un nœud ou un coordinateur unique.

Nom du paramètre	Description	Default
pgbouncer.default_pool_size	Définissez la valeur de ce paramètre sur le nombre de connexions par paire utilisateur/base de données.	295
pgbouncer.ignore_startup_parameters	Liste de paramètres séparés par des virgules que PgBouncer peut ignorer. Par exemple, vous pouvez laisser PgBouncer ignorer le paramètre extra_float_digits. Certains paramètres sont autorisés, tous les autres occasionnent une erreur. Cela est nécessaire pour tolérer un JDBC trop enthousiaste qui souhaite définir sans condition « extra_float_digits=2 » dans le paquet de démarrage. Utilisez cette option si la bibliothèque que vous utilisez signale des erreurs telles que pq: unsupported startup parameter: extra_float_digits.	extra_float_digits, ssl_renegotiation_limit
pgBouncer.max_client_conn	Définissez la valeur de ce paramètre sur le plus grand nombre de connexions clientes à PgBouncer que vous souhaitez prendre en charge.	2000
pgBouncer.min_pool_size	Ajoutez plus de connexions au serveur pour le pool si le nombre actuel est inférieur à celui défini.	0 (désactivé)
pgBouncer.pool_mode	Définissez cette valeur de paramètre sur TRANSACTION pour le regroupement de transactions (ce qui est le paramètre recommandé pour la plupart des charges de travail).	TRANSACTION
pgbouncer.query_wait_timeout	Durée maximale (en secondes) que les requêtes sont autorisées à passer en attente d’exécution. Si la requête n’est pas affectée à un serveur pendant ce temps, le client est déconnecté.	20 s
pgbouncer.server_idle_timeout	Une connexion de serveur ayant été inactive au-delà de ce nombre de secondes sera fermée. Si la valeur est 0, ce délai d’attente est désactivé.	60s

Paramètres PostgreSQL

• DateStyle : définit le format d'affichage des valeurs de date et d'heure
• IntervalStyle : définit le format d'affichage des valeurs d'intervalle
• TimeZone : définit le fuseau horaire pour l'affichage et l'interprétation des horodatages
• application_name : définit le nom de l'application à signaler dans les statistiques et les journaux
• array_nulls : permet l'entrée d'éléments NULL dans les tableaux
• autovacuum : lance le sous-processus de nettoyage automatique
• autovacuum_analyze_scale_factor : nombre d'insertions, de mises à jour ou de suppressions de tuple avant l'analyse, exprimé en fraction de reltuples
• autovacuum_analyze_threshold : nombre minimum d'insertions, de mises à jour ou de suppressions de tuple avant l'analyse
• autovacuum_naptime : durée de veille entre deux exécutions du nettoyage automatique
• autovacuum_vacuum_cost_delay : délai lié au coût du nettoyage, en millisecondes, pour le nettoyage automatique
• autovacuum_vacuum_cost_limit : montant du coût du nettoyage disponible avant la mise en veille, pour le nettoyage automatique
• autovacuum_vacuum_scale_factor : nombre de mises à jour ou de suppressions de tuple avant le nettoyage, exprimé en fraction de reltuples
• autovacuum_vacuum_threshold : nombre minimum de mises à jour ou de suppressions de tuple avant le nettoyage
• autovacuum_work_mem : définit la mémoire maximum à utiliser par chaque processus Worker de nettoyage automatique
• backend_flush_after : nombre de pages après lequel les écritures précédemment effectuées sont vidées sur le disque
• backslash_quote - Définit si le caractère « ’ » est autorisé dans les littéraux de chaîne
• bgwriter_delay : durée de veille entre deux cycles de l'enregistreur exécuté en arrière-plan
• bgwriter_flush_after : nombre de pages après lequel les écritures précédemment effectuées sont vidées sur le disque
• bgwriter_lru_maxpages : nombre maximum de pages LRU à vider par cycle de l'enregistreur exécuté en arrière-plan
• bgwriter_lru_multiplier : multiple de l'utilisation moyenne du tampon à libérer par cycle
• bytea_output : définit le format de sortie pour bytea
• check_function_bodies : vérifie le corps des fonctions pendant l'exécution de CREATE FUNCTION
• checkpoint_completion_target : temps passé à vider les tampons dont l'intégrité est compromise lors du point de contrôle, exprimé en fraction de l'intervalle entre deux points de contrôle
• checkpoint_timeout : définit le délai maximum entre deux points de contrôle automatiques du WAL
• checkpoint_warning : déclenche des avertissements si des segments de point de contrôle sont remplis plus fréquemment
• client_encoding : définit l'encodage du jeu de caractères du client
• client_min_messages : définit les niveaux des messages envoyés au client
• commit_delay : définit le délai, en microsecondes, entre la validation de la transaction et le vidage de WAL sur le disque
• commit_siblings : définit le nombre minimum de transactions ouvertes simultanées avant d'exécuter commit_delay
• constraint_exclusion : permet au planificateur d'utiliser des contraintes pour optimiser les requêtes
• cpu_index_tuple_cost : définit l'estimation par le planificateur du coût de traitement de chaque entrée d'index pendant une analyse d'index
• cpu_operator_cost : définit l'estimation par le planificateur du coût de traitement de chaque appel d'opérateur ou de fonction
• cpu_tuple_cost : définit l'estimation par le planificateur du coût de traitement de chaque tuple (ligne)
• cursor_tuple_fraction : définit l'estimation par le planificateur de la fraction récupérée des lignes d'un curseur
• deadlock_timeout : définit la durée d'attente sur un verrou avant de rechercher un blocage, en millisecondes
• debug_pretty_print : met en retrait les affichages de l'arborescence d'analyse et de planification
• debug_print_parse : consigne l'arborescence d'analyse de chaque requête
• debug_print_plan : consigne le plan d'exécution de chaque requête
• debug_print_rewritten : consigne l'arborescence d'analyse réécrite de chaque requête
• default_statistics_target : définit la cible des statistiques par défaut
• default_tablespace : définit l'espace disque logique par défaut où les tables et index doivent être créés
• default_text_search_config : définit la configuration par défaut de la recherche de texte
• default_transaction_deferrable : définit l'état de report par défaut des nouvelles transactions
• default_transaction_isolation : définit le niveau d'isolement de chaque nouvelle transaction
• default_transaction_read_only : définit l'état de lecture seule par défaut des nouvelles transactions
• default_with_oids : crée de nouvelles tables avec OID par défaut
• effective_cache_size : définit l'hypothèse du planificateur concernant la taille du cache de disque
• enable_bitmapscan : permet au planificateur d'utiliser des plans d'analyse bitmap
• enable_gathermerge : permet au planificateur d'utiliser des plans de regroupement et de fusion
• enable_hashagg : permet au planificateur d'utiliser des plans d'agrégation hachée
• enable_hashjoin : permet au planificateur d'utiliser des plans de jointure hachée
• enable_indexonlyscan : permet au planificateur d'utiliser des plans d'analyse d'index uniquement
• enable_indexscan : permet au planificateur d'utiliser des plans d'analyse d'index
• enable_material : permet au planificateur d'utiliser la matérialisation
• enable_mergejoin : permet au planificateur d'utiliser des plans de jointure de fusion
• enable_nestloop : permet au planificateur d'utiliser des plans de jointure de boucles imbriquées
• enable_seqscan : permet au planificateur d'utiliser des plans d'analyse séquentielle
• enable_sort : permet au planificateur d'utiliser des étapes de tri explicites
• enable_tidscan : permet au planificateur d'utiliser des plans d'analyse des TID
• escape_string_warning : signale la présence de barres obliques inverses d'échappement dans les littéraux de chaîne ordinaires
• exit_on_error : met fin à la session en cas d'erreur
• extra_float_digits : définit le nombre de chiffres affichés pour les valeurs à virgule flottante
• force_parallel_mode : force l'utilisation de fonctions de requêtes en parallèle
• from_collapse_limit : définit la taille de la liste FROM au-delà de laquelle les sous-requêtes ne sont pas réduites
• geqo : active l'optimisation génétique des requêtes (GEQO)
• geqo_effort : GEQO - un effort est fait pour définir la valeur par défaut d'autres paramètres GEQO
• geqo_generations : GEQO - nombre d'itérations de l'algorithme
• geqo_pool_size : GEQO - nombre d'individus au sein de la population
• geqo_seed : GEQO - seed pour la sélection de chemin aléatoire
• geqo_selection_bias : GEQO - pression sélective au sein de la population
• geqo_threshold : définit le seuil d'éléments FROM au-delà duquel l'optimisation GEQO est utilisée
• gin_fuzzy_search_limit : définit le résultat maximum autorisé pour une recherche exacte par GIN
• gin_pending_list_limit : définit la taille maximum de la liste en attente pour l'index GIN
• idle_in_transaction_session_timeout : définit la durée maximum d'inactivité autorisée pour toute transaction
• join_collapse_limit : définit la taille de la liste FROM au-delà de laquelle les constructions JOIN ne sont pas aplaties
• lc_monetary : définit les paramètres régionaux pour le formatage des valeurs monétaires
• lc_numeric : définit les paramètres régionaux pour le formatage des nombres
• lo_compat_privileges : active le mode de compatibilité descendante pour les vérifications de privilèges sur les objets volumineux
• lock_timeout : définit la durée maximum autorisée (en millisecondes) pour toute attente liée à un verrou. 0 désactive ce paramètre
• log_autovacuum_min_duration : définit le délai d'exécution minimum au-dessus duquel les actions de nettoyage automatique sont consignées
• log_connections : consigne chaque connexion réussie
• log_destination : définit la destination de la sortie du journal du serveur
• log_disconnections : consigne la fin d'une session, en indiquant sa durée
• log_duration : consigne la durée de chaque instruction SQL terminée
• log_error_verbosity : définit la verbosité des messages consignés
• log_lock_waits : consigne les longues attentes liées à un verrou
• log_min_duration_statement : définit la durée d'exécution minimum (en millisecondes) au-dessus de laquelle les instructions sont consignées. -1 désactive les durées des instructions de journalisation
• log_min_error_statement : permet de consigner toutes les instructions générant des erreurs à ce niveau ou à un niveau supérieur
• log_min_messages : définit les niveaux des messages consignés
• log_replication_commands : consigne chaque commande de réplication
• log_statement : définit le type d'instructions consignées
• log_statement_stats : pour chaque requête, inscrit les statistiques de performances cumulées dans le journal du serveur
• log_temp_files : consigne l'utilisation des fichiers temporaires dont la taille est supérieure à ce nombre de kilo-octets
• maintenance_work_mem : définit la mémoire maximum à utiliser pour les opérations de maintenance
• max_parallel_workers : définit le nombre maximum de Workers parallèles qui peuvent être actifs en même temps
• max_parallel_workers_per_gather : définit le nombre maximum de processus parallèles par nœud exécuteur
• max_pred_locks_per_page : définit le nombre maximum de tuples verrouillés par prédicat pour chaque page
• max_pred_locks_per_relation : définit le nombre maximum de pages et de tuples verrouillés par prédicat pour chaque relation
• max_standby_archive_delay : définit le délai maximum avant l'annulation des requêtes lorsqu'un serveur de secours traite des données WAL archivées
• max_standby_streaming_delay : définit le délai maximum avant l'annulation des requêtes lorsqu'un serveur de secours traite des données WAL diffusées en continu
• max_sync_workers_per_subscription : nombre maximum de Workers de synchronisation de table par abonnement
• max_wal_size : définit la taille du WAL qui déclenche un point de contrôle
• min_parallel_index_scan_size : définit la quantité minimum de données d'index pour une analyse parallèle
• min_wal_size : définit la taille minimum de réduction du WAL
• operator_precedence_warning : émet un avertissement pour les constructions qui ont changé de signification depuis PostgreSQL 9.4
• parallel_setup_cost : définit l'estimation par le planificateur du coût de démarrage des processus Worker pour l'interrogation en parallèle
• parallel_tuple_cost : définit l’estimation par le planificateur du coût du passage de chaque tuple (ligne) du Worker au back-end principal
• pg_stat_statements.save : enregistre les statistiques de pg_stat_statements en cas d'arrêt du serveur
• pg_stat_statements.track : sélectionne les instructions suivies par pg_stat_statements
• pg_stat_statements.track_utility : détermine si les commandes de l'utilitaire sont suivies par pg_stat_statements
• quote_all_identifiers : lors de la génération de fragments SQL, délimite tous les identificateurs
• random_page_cost : définit l'estimation par le planificateur du coût d'une page de disque récupérée de manière non séquentielle
• row_security : active la sécurité des lignes
• search_path : définit l’ordre de recherche des schémas pour les noms qui ne sont pas qualifiés par schéma
• seq_page_cost : définit l'estimation par le planificateur du coût d'une page de disque récupérée de manière séquentielle
• session_replication_role : définit le comportement de la session pour les déclencheurs et les règles de réécriture
• standard_conforming_strings : permet aux chaînes « ... » de traiter littéralement les barres obliques inverses
• statement_timeout : définit la durée maximum autorisée (en millisecondes) pour toute instruction. 0 désactive ce paramètre
• synchronize_seqscans : permet des analyses séquentielles synchronisées
• synchronous_commit : définit le niveau de synchronisation de la transaction actuelle
• tcp_keepalives_count : nombre maximum de retransmissions TCP Keepalive
• tcp_keepalives_idle : délai entre deux transmissions TCP Keepalive
• tcp_keepalives_interval : délai entre deux retransmissions TCP Keepalive
• temp_buffers : définit le nombre maximum de tampons temporaires utilisés par chaque session de base de données
• temp_tablespaces : définit le ou les espaces disque logiques à utiliser pour les tables temporaires et les fichiers de tri
• track_activities : collecte des informations sur l'exécution des commandes
• track_counts : collecte des statistiques sur l'activité de la base de données
• track_functions : collecte des statistiques au niveau des fonctions sur l'activité de la base de données
• track_io_timing : collecte des statistiques de minutage pour l'activité d'E/S de la base de données
• transform_null_equals : traite « expr = NULL » sous la forme « expr IS NULL »
• vacuum_cost_delay : délai lié au coût du nettoyage, en millisecondes
• vacuum_cost_limit : montant du coût du nettoyage disponible avant la mise en veille
• vacuum_cost_page_dirty : coût du nettoyage pour une page dont l'intégrité est compromise par le nettoyage
• vacuum_cost_page_hit : coût du nettoyage pour une page trouvée dans le cache de la mémoire tampon
• vacuum_cost_page_miss : coût du nettoyage pour une page introuvable dans le cache de la mémoire tampon
• vacuum_defer_cleanup_age : nombre de transactions en fonction desquelles les nettoyages VACUUM et HOT doivent être reportés, le cas échéant
• vacuum_freeze_min_age : âge minimum auquel VACUUM doit geler une ligne de la table
• vacuum_freeze_table_age : âge auquel VACUUM doit analyser toute la table pour geler les tuples
• vacuum_multixact_freeze_min_age : âge minimum auquel VACUUM doit geler un MultiXactId sur une ligne de la table
• vacuum_multixact_freeze_table_age : âge Multixact auquel VACUUM doit analyser toute la table pour geler les tuples
• wal_receiver_status_interval : définit l'intervalle maximum entre les rapports sur l'état du récepteur WAL
• wal_writer_delay : délai entre les vidages WAL effectués dans l'enregistreur WAL
• wal_writer_flush_after : quantité de WAL écrite par l'enregistreur WAL qui déclenche un vidage
• work_mem : définit la quantité de mémoire à utiliser par les opérations de tri internes et les tables de hachage avant d'écrire dans des fichiers des disques temporaires
• xmlbinary : détermine comment les valeurs binaires doivent être encodées en XML
• xmloption : détermine si les données XML des opérations d'analyse et de sérialisation implicites doivent être considérées comme des documents ou des fragments de contenu

Étapes suivantes

• Les options de configurationde ressource d’un cluster sont une autre forme de configuration.
• La base de données PostgreSQL sous-jacente a également des paramètres de configuration.