Skip to main content
Ces paramètres sont disponibles dans system.settings et sont générés automatiquement à partir du code source.

prefer_column_name_to_alias

Active ou désactive l’utilisation des noms de colonnes d’origine à la place des alias dans les expressions et clauses de requête. Ce paramètre est particulièrement important lorsque l’alias est identique au nom de la colonne ; voir Alias d’expression. Activez ce paramètre pour rendre les règles de syntaxe des alias dans ClickHouse plus compatibles avec celles de la plupart des autres moteurs de base de données. Valeurs possibles :
  • 0 — Le nom de la colonne est remplacé par l’alias.
  • 1 — Le nom de la colonne n’est pas remplacé par l’alias.
Si le nom de la colonne est ambigu entre les tables jointes et qu’un alias du même nom existe, l’alias est utilisé :
Ici, id dans id AS x est une colonne à la fois de t1 et de t3, il est donc résolu vers l’alias t1.id + 10. Exemple Différence entre l’état activé et désactivé : Requête :
Résultat :
Requête :
Résultat :

prefer_external_sort_block_bytes

Préférer des blocs de taille maximale pour le tri externe afin de réduire l’utilisation mémoire lors de la fusion.

prefer_global_in_and_join

Active le remplacement des opérateurs IN/JOIN par GLOBAL IN/GLOBAL JOIN. Valeurs possibles :
  • 0 — Désactivé. Les opérateurs IN/JOIN ne sont pas remplacés par GLOBAL IN/GLOBAL JOIN.
  • 1 — Activé. Les opérateurs IN/JOIN sont remplacés par GLOBAL IN/GLOBAL JOIN.
Utilisation Bien que SET distributed_product_mode=global puisse modifier le comportement des requêtes pour les tables distribuées, il ne convient pas aux tables locales ni aux tables provenant de ressources externes. C’est là que le paramètre prefer_global_in_and_join entre en jeu. Par exemple, nous avons des nœuds de service de requêtes qui contiennent des tables locales, lesquelles ne se prêtent pas à la distribution. Nous devons répartir leurs données à la volée lors du traitement distribué avec le mot-clé GLOBAL — GLOBAL IN/GLOBAL JOIN. Un autre cas d’usage de prefer_global_in_and_join est l’accès à des tables créées par des moteurs externes. Ce paramètre permet de réduire le nombre d’appels aux sources externes lors de la jointure de telles tables : un seul appel par requête. Voir aussi :

prefer_localhost_replica

Active ou désactive l’utilisation préférentielle de la réplique localhost lors du traitement des requêtes distribuées. Valeurs possibles :
  • 1 — ClickHouse envoie toujours une requête à la réplique localhost si elle existe.
  • 0 — ClickHouse utilise la stratégie d’équilibrage spécifiée par le paramètre load_balancing.
Désactivez ce paramètre si vous utilisez max_parallel_replicas sans parallel_replicas_custom_key. Si parallel_replicas_custom_key est défini, désactivez ce paramètre uniquement s’il est utilisé sur un cluster comportant plusieurs shards avec plusieurs répliques. S’il est utilisé sur un cluster comportant un seul shard et plusieurs répliques, désactiver ce paramètre aura des effets négatifs.

prefer_optimize_projection

Indique à l’optimisation des projections de privilégier les projections par rapport à la table dans les requêtes SELECT, lorsque l’optimisation des projections est activée (voir le paramètre optimize_use_projections). Lorsqu’il est activé, une projection pouvant répondre à la requête est utilisée même si elle nécessite la lecture de plus de marques que la table elle-même, comme avec force_optimize_projection, mais la requête n’échoue pas lorsqu’aucune projection ne peut être utilisée. Valeurs possibles :
  • 0 — Les projections sont choisies en fonction de leur coût estimé.
  • 1 — Une projection utilisable est choisie quel que soit son coût estimé.

prefer_warmed_unmerged_parts_seconds

N’a d’effet que dans ClickHouse Cloud. Si une part fusionnée date de moins de ce nombre de secondes et n’est pas préchauffée (voir cache_populated_by_fetch), mais que toutes ses parts sources sont disponibles et préchauffées, les requêtes SELECT liront ces parts à la place. Uniquement pour Replicated-/SharedMergeTree. Notez que cela vérifie uniquement si CacheWarmer a traité la part ; si la part a été mise en cache par un autre mécanisme, elle sera quand même considérée comme froide jusqu’à ce que CacheWarmer la traite ; si elle a été préchauffée puis évincée du cache, elle sera quand même considérée comme chaude.
Dernière modification le 26 septembre 2026