The old query analysis was removed, and `enable_analyzer` (canonically
`allow_experimental_analyzer`) is an obsolete setting frozen at `1`, so setting
it in tests does nothing. Remove it from stateless, integration, performance and
SQLStorm tests: drop `SET` statements, `SETTINGS` items, client options, loops
over both values and their echoed labels, and comments explaining why the
setting was pinned.
Tests of the obsolete setting itself are kept as they are:
`05136_analyzer_cannot_be_disabled`, `05210_analyzer_cannot_be_disabled_by_query_kind`,
`05292_analyzer_setting_float_value`, `04348_query_parameter_name_collides_with_setting`,
`04078_settings_constraints_compatibility_const`, `05099_client_options_exact_lookup`,
`03999_settings_history_baseline` and the `test_analyzer_compatibility` integration
test, which runs an old server version that still honours the setting.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`QueryAnalyzer::resolveFunction` looks up the function resolution cache
(`functions_cache`) using `function_node_ptr->getTreeHash()`. Computing
the tree hash traverses the entire argument subtree of every function
node, so resolving a chain of depth `D` functions costs `1 + 2 + ... + D`
node visits. At a fixed total number of function calls, this makes query
analysis grow with the nesting depth.
The new test `analyzer_nested_function_resolution` issues `EXPLAIN QUERY
TREE` over many chains of nested `abs` calls applied to a non-constant
base (`number + i`, so nothing is constant-folded). The total number of
function calls is fixed at 16384 across all four queries; only the
nesting depth varies (16, 64, 256, 1024). `EXPLAIN QUERY TREE` isolates
the analysis cost from execution, exposing the cost of the tree hashing
as a depth gradient.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Alexey Milovidov