> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# apply_* session settings

> ClickHouse session settings in the apply_* generated group.

export const SettingsInfoBlock = ({type, default_value, changeable_without_restart}) => {
  return <div className="not-prose" style={{
    display: "flex",
    flexWrap: "wrap",
    alignItems: "baseline",
    columnGap: "0.5rem",
    rowGap: "0.125rem",
    margin: "0.375rem 0",
    fontSize: "0.8125rem",
    lineHeight: "1.125rem"
  }}>
      <div style={{
    fontWeight: 600,
    opacity: 0.72
  }}>Type</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{type}</div>
      <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>Default</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          Changeable without restart
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

These settings are available in [system.settings](/docs/reference/system-tables/settings) and are autogenerated from [source](https://github.com/ClickHouse/ClickHouse/blob/master/src/Core/Settings.cpp).

<h2 id="apply_deleted_mask">
  apply\_deleted\_mask
</h2>

<SettingsInfoBlock type="Bool" default_value="1" />

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

<h2 id="apply_mutations_on_fly">
  apply\_mutations\_on\_fly
</h2>

<SettingsInfoBlock type="Bool" default_value="0" />

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

<h2 id="apply_prewhere_after_final">
  apply\_prewhere\_after\_final
</h2>

<SettingsInfoBlock type="Bool" default_value="0" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.12"},{"label": "0"},{"label": "New setting. When enabled, PREWHERE conditions are applied after FINAL processing."}]}]} />

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: If apply\_row\_level\_security\_after\_final is enabled and row policy uses non-sorting-key columns, PREWHERE will also
be deferred to maintain correct execution order (row policy must be applied before PREWHERE).

<h2 id="apply_row_policy_after_final">
  apply\_row\_policy\_after\_final
</h2>

<SettingsInfoBlock type="Bool" default_value="1" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.10"},{"label": "1"},{"label": "Setting was added as a fix for the post-#87303 regression where row policies and PREWHERE were applied before FINAL. PR #91065 introduced the setting and PR #97279 made the correctness-safe true the default. Recorded as {true, true} so compatibility never reverts to the pre-fix false behavior."}]}]} />

When enabled, row policies and PREWHERE are applied after FINAL processing for \*MergeTree tables. (Especially for ReplacingMergeTree)
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 depends only on columns in ORDER BY, it will still be applied before FINAL as an optimization,
since such filtering cannot affect the deduplication result.

Possible values:

* 0 — Row policy and PREWHERE are applied before FINAL (default).
* 1 — Row policy and PREWHERE are applied after FINAL.

<h2 id="apply_settings_from_server">
  apply\_settings\_from\_server
</h2>

<SettingsInfoBlock type="Bool" default_value="1" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.2"},{"label": "1"},{"label": "Client-side code (e.g. INSERT input parsing and query output formatting) will use the same settings as the server, including settings from server config."}]}]} />

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.