008. Reuse exact Float decomposition within SQL scopes

• Status: Superseded
• Date: 2026-10-13

The native PostgreSQL Float model in design 021 replaced the exact arithmetic decomposition path measured here. This record remains historical evidence for that earlier implementation; exact Float decomposition may still be used in unrelated structural sort keys.

Problem and mechanism

Exact PostgreSQL Float arithmetic lowers each HFF operand to its original Float SQL expression and an exact decomposition used by the arithmetic helpers. Repeated references to the same operand rebuilt those SQL fragments within a projection scope. The candidate caches the original Float expression and its exact decomposition separately in the existing sharedPaths scope. The final two-pass lowering preserves the original first-use order. It does not merge equal values from distinct SQL expressions, move work across scopes, or change per-operation presence handling. Caches reset at existing projection scope boundaries.

Applicability

Reproduction

The baseline is cdeff058. The candidate backends/sql/float_arithmetic.go source snapshot has SHA-256 6ec771e0289345f64dc1d67728e6184fd48718921ce554e1040c70c5392ffe78. The same arithmetic benchmark harness was added to the baseline and candidate:

• Build benchmark, SHA-256 afc75ea7d799da1e72ad9700065e845fe3fd46ada460a1abe9b67b2936fc68c2
• Execution benchmark, SHA-256 4282521126b944e54155490c99638533b17677788fe163c7c73ea51fe1baaab8

The eight workloads were CompareControl, Add, Subtract, Multiply, Divide, Repeated, Guarded, and Constant:

PostgreSQL execution covered all eight at 100 and 1,000 rows. The fixture included signed zero, subnormals, maximum finite Float, and null operands. The Guarded query checks null predicates; no-value guard behavior was covered by separate correctness tests. Each database sample checked returned IDs against local HFF before collecting PostgreSQL planning and execution. Only the Repeated SQL changed; the other 14 scripts were byte-identical.

The host was Darwin 25.2.0, arm64, Apple M3 Max with 64 GiB RAM. Go was 1.27.1 with default GOMAXPROCS=16. PostgreSQL was 18.6 in a Debian aarch64 container with image digest sha256:5a5a84b19854a9ffaa54082c166ff4ec27473a361e496e5ea167f298f2da9722. There were no explicit CPU, memory, or cpuset limits. JIT was off, parallel workers were disabled, custom plans were forced, and statement timeout was 60 seconds. The database directory used tmpfs. No retained-heap measurement was made.

Build command (three 200 ms samples per sub-benchmark):

GOTOOLCHAIN=go1.27.1 go test ./backends/sql -run '^$' \
  -bench '^BenchmarkPostgreSQLArithmeticBuild$/(CompareControl|Add|Subtract|Multiply|Divide|Repeated|Guarded|Constant)$' \
  -benchmem -benchtime=200ms -count=3

Execution command (use separate plan directories for baseline and candidate):

HFF_POSTGRES_CONTAINER=<container-name-or-id> \
HFF_POSTGRES_PLAN_DIR=/private/tmp/hff-arithmetic-plans \
GOTOOLCHAIN=go1.27.1 go test -tags=integration ./backends/sql -run '^$' \
  -bench '^BenchmarkPostgreSQLArithmeticExecution$/(100Rows|1000Rows)/(CompareControl|Add|Subtract|Multiply|Divide|Repeated|Guarded|Constant)$' \
  -benchtime=1x -count=3

Raw logs, SQL, plans, and IDs remain outside Git in /private/tmp/hff-arithmetic-evidence/ on the measurement host. The final baseline and candidate logs report the final paired source snapshots; earlier exploratory candidate runs are excluded.

Results

Build time is median ns/op with the three-sample min–max. Allocation is cumulative B/op, not retained or peak memory. The final candidate adds about 255 bytes and eight allocations to single-use arithmetic workloads; allocation counts fall for the repeated workload as generated SQL is shared.

Database results below are medians of three one-execution samples. Planning and execution timings for one-use cases vary only slightly in this selected fixture; the large difference is confined to Repeated.

Correctness and tradeoffs

Focused PostgreSQL parity tests cover repeated same-operand arithmetic, guards, captured and shadowed callback variables, and folds. The cache changes SQL only when a shared operand is reused; it does not alter operand order, numeric decomposition, exact arithmetic, or per-call presence behavior. The single-use cases show the Build cost of maintaining the cache. PostgreSQL does not guarantee physical expression evaluation order, and no retained-heap or production-service measurements were made.

Candidate validation:

• TMPDIR=/private/tmp HFF_WASM_NODE=<node-path> GOTOOLCHAIN=go1.27.1 sh hack/check.sh passed, including formatting, race tests, vet, generation checks, examples, WASM, and site checks.
• TMPDIR=/private/tmp GOTOOLCHAIN=go1.27.1 go vet -tags integration ./backends/sql passed.
• TMPDIR=/private/tmp GOTOOLCHAIN=go1.27.1 HFF_POSTGRES_CONTAINER=<container-name> go test -tags integration ./backends/sql -count=1 passed the full PostgreSQL integration suite (357.439s).

Decision and limits

Retain scoped reuse of the original Float expression and exact decomposition for repeated operands. The measured Build and PostgreSQL changes apply to the listed workloads and environment; they do not imply a general speedup for single-use arithmetic or other query shapes.