The ALL (multiset) counting map starts at 256 cells and grows by doubling,
so a large right input triggers a long resize cascade: repeated rehashing,
re-faulting of growing buffers, and a transient old+new buffer at each step.
Profiling shows the high-cardinality case is dominated by this memory
traffic, not by hashing.

Estimate the right (accumulated) input's row count in the planner by
walking its plan and summing source rows (`numbers` limit and
`ReadFromMergeTree` selected rows), and pass it through
`IntersectOrExceptStep` to the transform. After the first chunk, scale the
estimate by the observed distinct ratio and `reserve` the counting map once,
collapsing the cascade into a single allocation.

Cap the speculative reservation at 1/4 of the remaining query memory budget
(hard limit minus current usage), so a wrong over-estimate can never turn a
query that would otherwise fit into `MEMORY_LIMIT_EXCEEDED`. The table uses
the tracked `HashTableAllocator`, so the reserve is accounted and throws
cleanly rather than being OOM-killed. Also start the counting tables at
2^14 cells instead of 256 to skip the first resizes while reading the first
block.

On `SELECT count() FROM (numbers(20M) INTERSECT numbers(20M))` this lowers
peak memory ~33% (1.5 GiB to 1.0 GiB) and roughly halves the time
(1.3s to 0.7s), matching the resize-free path.

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

`addToSet` and `buildFilter` are only reachable for the DISTINCT operators;
the ALL operators use the counting path. Make that invariant explicit with
`chassert(!isAllOperator(), ...)` instead of relying on a comment, so a future
dispatch mistake fails loudly in debug builds.

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

The previous estimator summed leaf source rows, ignoring cardinality-changing
steps: e.g. a right operand `SELECT count() FROM numbers(1e9)` produces one
row but was estimated at 1e9, reserving the counting map for a billion keys.

Walk the operand plan and only derive an estimate when the output cardinality
is exact: propagate through `ExpressionStep` (1:1) and `UnionStep` (sum), use
`LimitStep` as a hard upper bound (skipping WITH TIES), and read source rows
only when no filter is pushed into the source. Any other step
(`AggregatingStep`, `FilterStep`, `DistinctStep`, sorts, joins, ...) returns
unknown, which skips the pre-reserve. MergeTree is treated as unknown (its
selected row count is not available at plan-build time).

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

Two fixes to estimatePlanOutputRows:

- LimitStep returned `limit` even when the child estimate was unknown, so
  `SELECT count() FROM numbers(1e9) LIMIT 1e9` (one row) could still reserve
  for a billion keys. `limit` bounds the output only if the child has at
  least `limit + offset` rows; with an unknown child, return unknown. It only
  ever caps a known child estimate, never raises it.

- Replace the `ExpressionStep` special-case with the step's
  `getTransformTraits().preserves_number_of_rows`. An `ExpressionStep` can
  contain `arrayJoin`, which is not row-preserving and is already encoded in
  the traits; this also generalizes to other row-preserving transforms.

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

The row estimate read `ReadFromSystemNumbersStep::getEstimatedRowsCount`
directly from the planner, which under thin-LTO pulled the step's
`storage->as<StorageSystemNumbers>()` (and thus `StorageSystemNumbers`'s
typeinfo) into `clickhouse-keeper`, which does not link storages:

    ld.lld: error: undefined symbol: typeinfo for DB::StorageSystemNumbers

Expose the per-source estimate as a virtual `getOutputRowsEstimate` on
`SourceStepWithFilterBase` (default unknown) and call it polymorphically, so
the planner no longer references the concrete numbers step and keeper does not
pull its vtable. The numbers override now also caps the count by a pushed-down
LIMIT, and the planner bails when a row-level or prewhere filter is present.

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

The pre-reserve was sized once from the first block's distinct ratio times the
row estimate. With the default `max_memory_usage = 0` its memory cap was
inactive, so a non-injective right operand (e.g. `if(number < 65536, number, 0)`
over a large input) whose first block looks all-distinct could reserve for ~1e8
keys though the final multiset holds ~65K, a multi-GiB upfront allocation.

Reserve from within `addToCounts` instead, driven by the table's own growth: the
per-row cost is just the already-computed inserted flag and a decrement (and is
compiled out for the fixed key8/key16 tables that cannot resize). Right before
the table would resize, an amortized review reserves straight to the estimate
once the live key count is within a factor of it, capped to a quarter of the
remaining memory budget. Inputs whose distinct count plateaus below the gate
never trigger a reserve and just grow naturally, so the bound holds even with no
memory limit set. With no estimate, small growing tables are pre-grown up to a
small bound; large ones fall back to the hash table's natural growth.

On `numbers(20M) INTERSECT numbers(20M)` this keeps ~0.7s and ~1.25 GiB, while
the pathological `if`-collapse drops from 4 GiB to 9 MiB and a low-cardinality
`number % 1000000` from 2 GiB to 79 MiB.

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

Master added `keys32` and `keys64` fixed-width variants to `SetVariants`
(`NonClearableSet`/`ClearableSet` and `APPLY_FOR_SET_VARIANTS`). Since
`CountingSet` is dispatched through the same macro, it must define the matching
members or the shared `init`/`getTotalRowCount`/`getTotalByteCount` expansions
fail to compile against it once this branch is merged with master:

    error: no member named 'keys32' in 'DB::CountingSet'

Add the counting (HashMap-backed) `keys32`/`keys64` members, mirroring the
existing `keys128`/`keys256`.

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

…ting-perf

Per review, the speedup comes entirely from keying the ALL multiset on the real
row value instead of a per-row `SipHash128` digest; the estimation-based
pre-sizing added complexity and a memory over-reservation footgun for only a
marginal, data-dependent gain (final table geometry, not resize-skipping).

Revert the on-demand reservation, the query-plan row estimate and its plumbing
(`IntersectOrExceptStep` / `ReadFromSystemNumbersStep` / `SourceStepWithFilter` /
`Planner`), and the custom counting-set grower. `CountingSet` now uses the default
grower, exactly like the DISTINCT path's `NonClearableSet`. Improving INTERSECT/
EXCEPT memory will be handled separately.

`SELECT count() FROM (numbers(20M) INTERSECT numbers(20M))`: ~6.8s -> ~0.7s; peak
memory 2.25 GiB -> 1.5 GiB (narrower cell, no digest). The INTERSECT/EXCEPT test
suite and results are unchanged.

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