`StorageSnapshot::getColumns(All|Subcolumns|...)` is called from
`QueryAnalyzer::initializeTableExpressionData` for every table in every
query. For a wide table such as `hits` it spent ~3% of the per-query
TCPHandler CPU on two avoidable things:

* Building a `NameSet` over every regular column of the table just to
  filter out a handful of virtuals. With ~110 columns and ~5 virtuals,
  a linear `find` per virtual is cheaper than hashing all 110 names.

* Calling `VirtualColumnsDescription::getSampleBlock` to obtain
  names/types of virtuals. That constructs a full `Block`, which calls
  `IDataType::createColumn()` per virtual just so the result can be
  destructured into a `NamesAndTypesList` immediately after.

Add `VirtualColumnsDescription::getNamesAndTypes(kind, place)` that
emits the same names/types directly, fast-path the
`metadata->virtuals.empty()` case in `StorageSnapshot::getColumns`, and
do a linear de-dup against `all_columns` instead of building a hash set.

Measured on clickbench Q0 `SELECT count() FROM hits`:
* ~995 -> ~1019 QPS (+2.4%)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

For wide tables (e.g. ClickBench `hits`, ~100 columns), populating the
`name -> ColumnNode` map for every column on every query during
`initializeTableExpressionData` is the dominant analyzer cost when the
query touches no column identifiers (`SELECT count() FROM t`).

Build only the cheap membership-check sets (`column_names`,
`column_identifier_first_parts`) eagerly and defer the
`ColumnNode`-allocating map to first use via a `populate_column_node_map`
closure. The closure also takes over ALIAS column resolution that the
old eager path performed inline, so it captures the storage snapshot and
the parent `IdentifierResolveScope` and runs only when an identifier
actually requires a `ColumnNode`.

`column_name_to_column_node` becomes `std::optional<map>` so
`has_value()` doubles as the populated flag. `ensureColumnNodeMapIsPopulated`
emplaces the empty map up front so re-entrant lookups during alias
expression resolution (e.g. `y ALIAS x + x*2` looking up `x`) see the
placeholder ColumnNodes the populator has already inserted.

Subqueries / unions still populate eagerly: their projection lists are
small and the map is needed immediately by the surrounding resolution.

ClickBench Q0 (`SELECT count() FROM hits`): ~1019 -> ~1216 QPS (+19%).
Wider impact wherever a query references few columns of a wide table.

After making `column_name_to_column_node` lazy, perf showed
`initializeTableExpressionData` still spending ~1.4% inserting
`column_names` strings and ~1.0% constructing `Identifier` objects to
populate `column_identifier_first_parts` for every column of the table.

These two sets are membership-check helpers used only when an identifier
is being bound to a table expression. Trivial queries like
`SELECT count() FROM t` never consult them, so move their construction
into `ensureColumnMembershipSetsArePopulated()`, called on demand from
`hasFullIdentifierName`, `canBindIdentifier`, `tryGetSubcolumnInfo`, and
the JOIN USING parent-scope check.

`ensureColumnNodeMapIsPopulated` calls the membership-set populator
first so any code path that needs the `ColumnNode` map continues to see
a fully built table expression data.

ClickBench Q0 (`SELECT count() FROM hits`): ~1216 -> ~1350 QPS (+11%).

Analyzer and planner each call `StorageSnapshot::getColumns` once per query
with the same option set (`All|Virtuals|Subcolumns` from the analyzer,
`AllPhysical|Subcolumns` from the planner). Each call iterates the
columns multi-index and runs `addSubcolumnsToList` (one hash lookup in
`columns` and one `equal_range` on `subcolumns` per row) — O(N + N*M) work
on every query, ~2.7% of CPU on `SELECT count() FROM hits` for a wide
table.

Move the memoization to `ColumnsDescription::get`, where it lives for the
lifetime of the descriptor (i.e. one StorageInMemoryMetadata version).
Two queries on the same table version reuse the same cached
`NamesAndTypesList`s. The cache is keyed by the four scalar fields of
`GetColumnsOptions`, packed into a 4-byte struct, and a small linear
search is fast enough for the handful of distinct option sets a query
mix produces.

Every mutator that touches `columns` or `subcolumns` (`add`, `remove`,
`rename`, `modifyColumnOrder`, `flattenNested`, `addSubcolumns`,
`removeSubcolumns`, copy/move assignment) calls `invalidateGetCache` so
ALTER and similar paths see consistent data.

ClickBench Q0 (`SELECT count() FROM hits`): ~1352 -> ~1397 QPS (+3%).

`CurrentMemoryTracker::allocImpl` and `free` are called on every
allocation. Three small wins on the hot path:

* Read `current_thread` once. The previous flow went through a local
  `getMemoryTracker()` that already loaded `current_thread`, then a
  follow-up `if (!current_thread)` that issued a second TLS load and
  branch.
* Skip the unconditional store to `untracked_memory_blocker_level`. The
  blocker level only changes when a `MemoryTrackerBlockerInThread` is
  pushed/popped, which is rare; the common case wrote the same value
  back every allocation.
* Move the global-tracker fallback into out-of-line `[[gnu::cold]]`
  helpers (`allocWithoutCurrentThread`, `freeWithoutCurrentThread`) so
  the cold path doesn't bloat the hot one.

Tagged the rare branches with `[[unlikely]]`. ClickBench Q0 shows
`allocImpl` self-time drop from ~0.86% to ~0.70% on the perf profile;
roughly 0.15% of total CPU on the new/delete fast path.

`buildQueryPlanForTableExpression` set up the trivial-count plan and
then ran an entire `Planner` over the same query (with `only_analyze`)
just to read back the expected header at `WithMergeableState` and add
a rename `ExpressionStep` if the trivial-count block disagreed. On
ClickBench Q0 (`SELECT count() FROM hits`) that recursive planner was
~4.6% of total CPU, and the rename it produced was always the same:
"alias the smallest-column name to the aggregate's identifier."

Construct the trivial-count block with the aggregate's
`calculateActionNodeName` directly, so its header already matches the
one the outer planner expects. Then skip the recursive `Planner`
whenever trivial-count was applied -- nothing else can change the
header at that point, since the only steps gated on
`till_stage == FetchColumns` (alias columns, where filters) don't
fire after the trivial-count branch.

Plan goes from `Expression(Project) -> MergingAggregated -> Expression(Change column names) -> ReadFromPreparedSource`
to `Expression(Project) -> MergingAggregated -> ReadFromPreparedSource`.

Three reference files updated to reflect the dropped Expression step:
* `03448_trivial_count_single_threaded_merge.reference` -- one less
  level in `EXPLAIN PIPELINE`.
* `04061_trivial_count_aggregate_function_argument_types.reference` --
  the second `Header:` line came from the rename step's output and is
  no longer present.
* `04201_trivial_count_with_additional_filter.reference` -- one less
  indentation level around `(ReadFromPreparedSource)`.

ClickBench Q0: ~1383 -> ~1444 QPS (+4.4%).

Two clang-tidy errors reported by the arm_tidy build:

1. `src/Storages/ColumnsDescription.h`:
   `bugprone-copy-constructor-init`: the explicit copy / move
   constructors did not initialize the `IHints<>` base, leaving it
   default-constructed.

2. `src/Planner/PlannerJoinTree.cpp`:
   `performance-move-const-arg`: `std::move` on
   `trivial_count_column_name` had no effect because
   `ColumnWithTypeAndName`'s constructor takes `const String &`.

`IHints<>` is stateless, but `IHints<>(std::move(other))` plus subsequent
`std::move(other.columns)` triggers `bugprone-use-after-move`. The implicit
base move-construction is sufficient.

…n change

Follow-up to 4c85254 (Skip the recursive Planner after trivial-count
optimization), which dropped one `Expression` / `ExpressionTransform`
step from the trivial-count plan in the analyzer path. Three other
references were updated in that commit; this one was missed.

Only the `enable_analyzer = 1` half changes (lines 9-16): one nested
`Expression` layer above `(ReadFromPreparedSource)` is removed,
reducing the indentation by two spaces. The `enable_analyzer = 0`
half is unchanged -- the old interpreter wasn't touched.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…fsets-cache

`ColumnsDescription.h` had a stale `#include <mutex>` from when
`get_cache_mutex` was `std::mutex`; it's now `DB::SharedMutex` and no
inline body in the header uses `std::lock_guard` / `std::mutex`. The
.cpp uses `std::lock_guard<SharedMutex>` on the exclusive sites, so
include `<mutex>` explicitly there.