Skip to main content
These settings are available in system.settings and are autogenerated from source.

short_circuit_function_evaluation

Allows calculating the if, multiIf, and, and or functions according to a short scheme. This helps optimize the execution of complex expressions in these functions and prevent possible exceptions (such as division by zero when it is not expected). Possible values:
  • enable — Enables short-circuit function evaluation for functions that are suitable for it (can throw an exception or computationally heavy).
  • force_enable — Enables short-circuit function evaluation for all functions.
  • disable — Disables short-circuit function evaluation.

short_circuit_function_evaluation_for_nulls

Optimizes evaluation of functions that return NULL when any argument is NULL. When the percentage of NULL values in the function’s arguments exceeds the short_circuit_function_evaluation_for_nulls_threshold, the system skips evaluating the function row-by-row. Instead, it immediately returns NULL for all rows, avoiding unnecessary computation. This setting controls an optimization only. Functions that cannot be executed on the default value of their arguments - such as parseDateTime, IPv4StringToNum or intDiv - always skip the rows containing a NULL regardless of this setting, because the value stored behind a NULL is the default value of the argument type and executing on it would throw on otherwise valid data.

short_circuit_function_evaluation_for_nulls_threshold

Ratio threshold of NULL values to execute functions with Nullable arguments only on rows with non-NULL values in all arguments. Applies when setting short_circuit_function_evaluation_for_nulls is enabled. When the ratio of rows containing NULL values to the total number of rows exceeds this threshold, these rows containing NULL values will not be evaluated.

short_circuit_function_evaluation_reorder_arguments

Allows changing the order in which the arguments of the and and or functions are evaluated with short-circuit evaluation, when it does not change the result and does not introduce exceptions.
  • If the first argument is computationally heavy and another argument is cheap, the cheap argument is evaluated first, and the heavy one is evaluated only on the rows where the result is not yet decided. For example, in WHERE JSONExtractString(json, 'a') = 'x' AND id < 100 the JSON is parsed only for the rows with id < 100.
  • The arguments that are evaluated lazily and cannot throw an exception are evaluated in the order of increasing time per row they decide, as measured on the previous blocks. The arguments that can throw an exception keep all the arguments that precede them in front of them, so that, for example, x != 0 AND intDiv(1, x) > 0 never divides by zero.