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” scenariosapply_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 byapply_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 (seeapply_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 likeALTER 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.