apply_* session settings

These settings are available in system.settings and are autogenerated from source.

​

apply_deleted_mask

Enables filtering out rows deleted with lightweight DELETE. If disabled, a query will be able to read those rows. This is useful for debugging and “undelete” scenarios

​

apply_mutations_on_fly

If true, mutations (UPDATEs and DELETEs) which are not materialized in data part will be applied on SELECTs.

​

apply_prewhere_after_final

When enabled, PREWHERE conditions are applied after FINAL processing for ReplacingMergeTree and similar engines. This can be useful when PREWHERE references columns that may have different values across duplicate rows, and you want FINAL to select the winning row before filtering. When disabled, PREWHERE is applied during reading. Note: PREWHERE is also deferred, regardless of this setting, whenever a row policy is deferred by apply_row_policy_after_final, because the row policy must be applied before PREWHERE. That happens when the policy expression is non-deterministic, or reads a column that is not in ORDER BY, or reads an ORDER BY column whose type is or contains a floating-point type. Possible values:

• 0 — PREWHERE is applied before FINAL, unless a deferred row policy defers it too (default).
• 1 — PREWHERE is applied after FINAL.

​

apply_row_policy_after_final

When enabled, row policies are applied after FINAL processing for *MergeTree tables. (Especially for ReplacingMergeTree) When the policy is deferred this way, PREWHERE is deferred with it so that the policy is still applied first (see apply_prewhere_after_final for deferring PREWHERE unconditionally). When disabled, row policies are applied before FINAL, which can cause different results when the policy filters out rows that should be used for deduplication in ReplacingMergeTree or similar engines. If the row policy expression is deterministic and depends only on non-floating-point columns in ORDER BY, it will still be applied before FINAL as an optimization, since such filtering cannot affect the deduplication result. Floating-point columns or columns containing floating-point (such as Tuple(Float64, ...), Array(Float64), Nullable(Float64), etc.) are excluded because -0.0 and 0.0 deduplicate as one key while a policy condition can tell them apart. Possible values:

• 0 — Row policy is applied before FINAL.
• 1 — Row policy is applied after FINAL (default).

​

apply_settings_from_server

Whether the client should accept settings from server. This only affects operations performed on the client side, in particular parsing the INSERT input data and formatting the query result. Most of query execution happens on the server and is not affected by this setting. Normally this setting should be set in user profile (users.xml or queries like ALTER USER), not through the client (client command line arguments, SET query, or SETTINGS section of SELECT query). Through the client it can be changed to false, but can’t be changed to true (because the server won’t send the settings if user profile has apply_settings_from_server = false). Note that initially (24.12) there was a server setting (send_settings_to_client), but latter it got replaced with this client setting, for better usability.

​

apply_string_filters_during_scan

Push down substring search conditions on String columns from PREWHERE into the column scan. When a PREWHERE condition contains a conjunct that searches for a non-empty substring in a String (or Nullable(String)) column (LIKE, position, startsWith, endsWith, or equality with a non-empty string), the reader checks every value against this condition during deserialization and reads non-matching values as empty strings. This makes reading faster and lowers memory usage when the condition is selective, because the data of non-matching values is not copied into the column. The result of the query does not change, because the rows with non-matching values are guaranteed to be filtered out by PREWHERE, and such conditions never match an empty string. The filter is disabled adaptively at runtime if it turns out to be non-selective. Also allows the WHERE to PREWHERE optimization to move substring search conditions (LIKE, position, startsWith, endsWith) even when they use all queried columns (normally that is pointless, but with this setting the scan itself becomes cheaper). Equality with a constant string is not moved for this reason: it is still applied during the scan when it is already in PREWHERE. Supported for reading from MergeTree tables and from the Parquet format. Note that the estimation of the input bytes collected for the automatic decision about parallel replicas (RuntimeDataflowStatisticsInputBytes) is based on the in-memory size of the read blocks, so it underestimates the amount of data read from disk when the values are replaced by empty strings. Possible values:

• 0 — Disabled.
• 1 — Enabled.