041. Reuse native identity results and proven presence

• Status: Implemented
• Date: 2026-10-14

Problem and mechanism

Some PostgreSQL expressions projected a value again even when a built-in operation returned its input unchanged, or projected a separate presence value that was already statically TRUE. The translator can now reuse an existing operand projection for Int- and Null-valued round(), ceil(), and floor() views and for native Duration nanoseconds(). The identity view retains the operand's no-value state; SQL NULL remains a value-level null.

The translator also removes tautological presence conditions when the later operand's presence is proven TRUE in eligible arithmetic, collection, JSON access, regex, and method expressions. Presence depending on a guard or runtime value remains explicit. Float rounding remains computed according to the PostgreSQL Float profile. Dynamic JSON values retain their decoding; a subsequent native Int identity view can still reuse that decoded result.

Applicability

Reproduction

The baseline is commit b739cf4. The fixture used Go 1.27.1 on Darwin/arm64 and PostgreSQL 18.6 on Debian/aarch64 with extra_float_digits=1. It measured generated WHERE bytes, OFFSET 0 barriers, and argument counts; no timing benchmark or execution-time measurement was made.

The paired PostgreSQL/local fixture evaluated 49 filters over 121 records, for 5,929 comparisons on both the baseline and candidate. Its Int inputs include null, both int64 limits, negatives, zero, and positives. It includes callback captures, Boolean short-circuiting, and dynamic Duration parsing with valid and invalid strings. The temporary shape fixture used nullable and required native Int, Float, String, Bool, Bytes, and Duration columns, plus a List<Int> and Map<Any> JSON binding. Representative queries were:

i:round:json=i:floor:json
i:ceil:floor:round:json=i:json
d:nanoseconds:json=i:json
d!:nanoseconds:json=d:nanoseconds:json
data.n:[int]:round:json=i:json
items:any(x=>x:round+1>i)
i+2>10
p:and(q):type="bool"

The durable paired test is TestPostgreSQLNativeOperationReuseMatchesLocal in native_operation_cache_integration_test.go. Run it with:

HFF_POSTGRES_CONTAINER=<container> GOTOOLCHAIN=go1.27.1 go test -tags=integration ./backends/sql -run '^TestPostgreSQLNativeOperationReuseMatchesLocal$'

The shape generator and emitted SQL were temporary artifacts. Its table and bindings followed the native operation reuse fixture without the paired test's words column. The queries and binding families above describe the measured SQL-shape inputs; the paired integration fixture is the semantic comparison. Plain EXPLAIN was run on an empty temporary table without ANALYZE.

Results

Generated WHERE byte counts and OFFSET 0 barriers for representative nullable-profile cases:

Argument counts were unchanged for each case. Plain plans on the empty fixture had fewer nested-loop nodes for the first Int rounding filter (four to two), the chained Int views (five to two), native Duration view (three to two), guarded Duration case (five to three), and dynamic JSON case (nine to eight). These plan observations are fixture-specific; they do not establish execution speed or behavior on populated tables.

Correctness and tradeoffs

The paired fixture passed all 5,929 PostgreSQL/local comparisons against both baseline and candidate. Controls confirmed that Float round() remains computed, dynamic JSON Any values retain their ordinary parsing, and guard-derived presence remains explicit. An extension observing pg_typeof confirmed that Int identity views retain a bigint carrier and Float rounding retains double precision; an invalid numeric conversion followed by round() retains its folded-null carrier. The identity aliases preserve the original carrier and presence, and the simplification applies only when presence is statically known to be TRUE.

Decision and limits

Reuse only the listed identity views and statically proven presence values. Other computed methods and runtime-dependent presence retain their existing lowering. SQL-shape and plain-plan observations are not runtime-speed claims.