fix: preserve prepared ROUND and TRUNCATE value domains

[XuPeng-SH]

What type of PR is this?

• BUG

Which issue(s) this PR fixes:

Closes #29505
Closes #29509
Closes #29471
Closes #29506
Closes #29511
Closes #29512
Closes #29510

What this PR does / why we need it:

• Keep the prepared ROUND/TRUNCATE value argument's numeric domain open until EXECUTE, while the precision argument retains its integer domain. Rebuild cached expressions with all arguments and preserve explicit CAST and set-operation output domains ([Bug]: Prepared ROUND/TRUNCATE lose runtime numeric domain #29505).
• Keep the prepared generation and snapshot binding when EXPLAIN ANALYZE FORCE EXECUTE compiles the executable plan ([Bug]: EXPLAIN ANALYZE FORCE EXECUTE fails on prepared plan snapshot binding #29509).
• Serialize JSON-to-CHAR expression casts with JSON string quotes while preserving existing assignment behavior ([Compatibility]: JSON-to-character CAST unquotes JSON strings instead of serializing them #29471).
• For prepared integer-key comparisons, prove that an integral text/float binding can use the native integer domain without changing existing DOUBLE comparison results; preserve fallback at and beyond the signed 2^53 collision boundary, for fractional/malformed/out-of-range values, and for unsigned edge cases. Carry the existing prepared diagnostic proof into executable EXPLAIN so its actual scan uses the block filter ([Bug]: Prepared non-integer values on signed BIGINT keys lose block filtering #29506).
• For SELECT comparisons between an integer key and a wider or differently signed integer binding, narrow only a proven safe runtime value to the key domain. Preserve the existing fallback for out-of-range, negative-to-unsigned, and 2^53 collision values. Keep DML on its existing type-stable cache path ([Performance]: Wider integer bindings suppress native filters on INT and UNSIGNED keys #29511).
• Preserve native BIGINT filtering for prepared ROUND/TRUNCATE with zero precision when the text binding is provably an exact integer. Cover direct, scalar-subquery, and projected-marker shapes; retain comparison fallback for fractional, unsafe, NULL, and explicit-CAST inputs ([Performance]: Prepared ROUND numeric text can disable BIGINT filter pushdown #29512).
• Preserve native DECIMAL filtering when a DOUBLE peer maps to exactly one value at the column scale. Reuse the existing comparison type selection and prepared binding state. Fall back for values between DECIMAL scale points, out-of-range values, nonfinite values, and floating-point collisions at large magnitudes ([Performance]: DOUBLE comparison on DECIMAL column loses block filtering #29510).

Design: reuse the existing prepared binding, expression-reset, and compile owners. The value-dependent proof uses the existing binding-state cache guard; no parallel cache or execution state machine was added.

Validation

• Full UT: go test -p 1 -mod=readonly ./pkg/sql/plan/function ./pkg/sql/plan ./pkg/sql/compile ./pkg/frontend -count=1 passed on the final [Performance]: DOUBLE comparison on DECIMAL column loses block filtering #29510 source.

• Focused race UT across the same four packages passed, including prepared integer comparison, ROUND/TRUNCATE, JSON cast, executable EXPLAIN, and block-filter proof tests.

• Incremental SCA: gofmt, go vet, golangci-lint 2.5.0 with Go 1.26; 106 changed Go files / 11 packages against the original fix: restore prepared TPCC filter selectivity with per-binding proof #29462 base, 0 issues.

• BVT on the [Performance]: DOUBLE comparison on DECIMAL column loses block filtering #29510 final source: [Performance]: DOUBLE comparison on DECIMAL column loses block filtering #29510 31/31, [Performance]: Prepared ROUND numeric text can disable BIGINT filter pushdown #29512 44/44, [Performance]: Wider integer bindings suppress native filters on INT and UNSIGNED keys #29511 34/34, [Bug]: Prepared non-integer values on signed BIGINT keys lose block filtering #29506 40/40, [Bug]: EXPLAIN ANALYZE FORCE EXECUTE fails on prepared plan snapshot binding #29509 16/16, [Compatibility]: JSON-to-character CAST unquotes JSON strings instead of serializing them #29471 8/8, [Bug]: Prepared ROUND/TRUNCATE lose runtime numeric domain #29505 15/15, existing [Bug]: Full TPCC suite accumulates long-lived row locks and cascades into lock wait timeouts #29429 71/71.

• Black-box [Performance]: Wider integer bindings suppress native filters on INT and UNSIGNED keys #29511 scan QA on a 100,000-row table: safe INT and UNSIGNED BIGINT integer bindings each read 1 block; out-of-range and negative-to-unsigned bindings retained the old fallback and rows. Binary prepared int32/int64 bindings were executed 100 times each; existing DML compile-cache UT was retained.

• Black-box [Bug]: Prepared non-integer values on signed BIGINT keys lose block filtering #29506 scan QA on a 100,000-row/13-block table: an integral text binding and native constant each read 1 block under EXPLAIN ANALYZE FORCE EXECUTE; fractional text conservatively retained the prior scan and result. SQL and binary-protocol bindings, malformed text, BETWEEN/IN, INT32/BIGINT, and the signed 2^53 collision boundary were challenged.

• Sequential TPCC 10-10, three minutes per version, independently cloned from the same GOOD-readable dataset snapshot: this head 4699.34 tpmC, GOOD predecessor 4842.22 tpmC (head -2.95%), 0 transaction errors on both. A separate same-dataset isolation of pre-[Bug]: Prepared non-integer values on signed BIGINT keys lose block filtering #29506 head versus [Bug]: Prepared non-integer values on signed BIGINT keys lose block filtering #29506 head was 4153.94 versus 4148.88 tpmC (-0.12%), both 0 errors. These short local runs establish no measurable incremental TPCC regression from [Bug]: Prepared non-integer values on signed BIGINT keys lose block filtering #29506; the full head-to-GOOD difference remains visible and is not claimed resolved.

• Sequential same-snapshot TPCC 10-10, three minutes per version, isolating [Performance]: Wider integer bindings suppress native filters on INT and UNSIGNED keys #29511: previous head 7552144822 4449.74 tpmC versus [Performance]: Wider integer bindings suppress native filters on INT and UNSIGNED keys #29511 candidate 5019.17 tpmC (+12.8%), 0 errors both. One short local run does not establish a stable throughput gain but shows no obvious incremental regression.

• [Performance]: Prepared ROUND numeric text can disable BIGINT filter pushdown #29512 black-box scan QA on 100,000 rows / 13 blocks: safe direct, scalar-subquery, and derived-table bindings read 1 block; fractional input kept the 13-block fallback. Binary-protocol output matched the prior head across string, bytes, float, NULL, malformed, and 2^53 boundary inputs. An explicit SQL CAST kept its prior comparison plan.

• Sequential same-snapshot TPCC 10-10, one-minute warmup and three-minute measurement per version, isolating [Performance]: Prepared ROUND numeric text can disable BIGINT filter pushdown #29512: previous head c0df2e8848 4121.35 tpmC versus [Performance]: Prepared ROUND numeric text can disable BIGINT filter pushdown #29512 4410.47 tpmC (+7.0%), 0 errors both. This short local run shows no observed incremental regression, not a stable throughput gain.

• [Performance]: DOUBLE comparison on DECIMAL column loses block filtering #29510 black-box SQL and binary-protocol QA: on 100,000 rows / 13 blocks, d=CAST(54321 AS DOUBLE) improved from 13 scanned blocks to 1. On the same data, 50 binary prepared float64 lookups took 3.11 s on the prior head versus 0.060 s here. A fractional value between DECIMAL scale points (0.104) retained the old result and fallback time (2.99 s versus 2.92 s for 50 executions). Binary prepared results matched the prior head for safe/fractional/negative/out-of-range/NULL/nonfinite values and the signed 2^53 collision boundary.

• Sequential same-snapshot TPCC 10-10, one-minute warmup and three-minute measurement per version, isolating [Performance]: DOUBLE comparison on DECIMAL column loses block filtering #29510: prior head d5dbf37838 4336.69 tpmC versus [Performance]: DOUBLE comparison on DECIMAL column loses block filtering #29510 4555.56 tpmC (+5.0%), 0 transaction errors both. This short run shows no observed incremental regression; it is not a stable throughput gain.

Follow-up QA

The fix is scoped to comparisons where a unique DECIMAL value can be proven. Other expression shapes and full sysbench/TPC-H/ClickBench workload performance remain subject to broader QA.

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →