test: enforce prepared DECIMAL peer pruning and binding reuse

[XuPeng-SH]

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

Related to #29515. The production optimization already landed in #29508. This PR repairs its regression coverage; it does not automatically close the issue or claim to explain the conflicting latest report.

What this PR does / why we need it:

The existing #29515 BVT ignores the entire EXPLAIN ANALYZE column, including the scan counters that distinguish the reported performance defect from a correct result. It also checks only COUNT, which cannot distinguish a stale safe binding from a new safe binding returning a different row.

• Assert the target table scan's actual inputBlocks=1 inputRows=8192 for direct, scalar, ABS, scalar ABS, singleton derived and derived ABS forms, plus the existing second-parameter case. Match the scan's immediately following Analyze row, excluding timings and memory statistics.
• Reuse each prepared generation through safe → unsafe → NULL → negative → different safe → recovered safe bindings. Check COUNT and MIN separately from scan pruning, so same-type value reuse is observable.
• Replace the first generated value with 0.10, preserving the existing 100,000-row sorted fixture. Incorrectly narrowing DOUBLE 0.104 to the stored DECIMAL value now causes a result failure.
• Keep existing 2^53 collision, nonconstant derived, CAST and malformed-text/warning controls. Do not freeze the unsafe fallback's scan volume.
• Keep only result headers for regex-owned ANALYZE statements; the SQL regex checks actual output. Remove redundant volatile plan bodies. No new fixture, process, cache or production path.

Implementation: 0 changed production lines. Tests: SQL +78 net lines, result +58 net lines; documentation: 0. Every added execution observes a distinct expression/binding transition. The existing fixture and topology are reused.

Validation

Linux/amd64, Go 1.26.4, matching native dependencies; independently built main d59cc02ef6 release binary with SIMD, isolated one-CN/TN/LOG instance and DISK-V2 storage. Tested with the published mo-tester runtime jar from main 309a0ca (the compose CI Dockerfile clones mo-tester main).

• Original BVT: 163/163. Updated BVT: 213/213 twice on the same instance, zero failed/ignored/abnormal; explicit catalog teardown checked before replay and after the final run. Reported case duration remained 1 second on this machine, not a throughput benchmark.
• Actual mo-tester ScriptParser/Java regex QA: all 21 assertions accept healthy plans and reject scan-only 13-block/100,000-row mutations, missing counters and a different table name, with aggregate rows preserved.
• Public SQL negative control: a scalar predicate that scans all 13 blocks retains all COUNT/MIN results; exactly its three ANALYZE assertions fail (210 other statements pass). This proves the new oracle detects the performance defect independently of result correctness.
• Current-main public reproduction on DECIMAL(18,2), with and without manual flush: all six safe shapes read one block. Thirty-six SQL PREPARE binding transitions passed.
• Independent binary-protocol QA: 80 comparisons matched explicit column-side DOUBLE comparison across fractional/negative/NULL/nonfinite values, positive and negative 2^53 collisions, and recovery.
• Existing focused planner test TestPreparedNumericPredicateFiltering passed at the unchanged production revision. git diff --check passed. No Go files changed, so new Go SCA, full UT or race reruns are not required for this SQL/result-only closure.

Review and remaining limitation

Design and final overall review used actual gpt-6.1-sol / xhigh, session 01a0fca6-9b52-7d22-ae0e-518dd340da19. Final decision: APPROVE, no unresolved material blocker. Commit bf1cd887bd41c4ed8f20a089928480117f89f4c7 preserves the reviewed complete-diff SHA-256 dce4fe300e9653534e469f209c7329b97ee4b210f6dab6a7ad493835c4c1b0b5.

The latest issue comment reports 13-block scans on d50a2d4; that behavior was not reproduced on this independently built current main. The relevant planner/binding/frontend sources are identical between those revisions. A rendered DOUBLE cast alone does not establish full scanning: current plans can display it while their actual scan reads one block. The comment's binary/configuration/execution discrepancy remains unexplained.

This test-only change introduces no production runtime overhead. Local validation does not claim remote CI passed; CI is not awaited or rerun.

[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 →

[LeftHandCold]

Reviewed the complete two-file diff at bf1cd887bd41c4ed8f20a089928480117f89f4c7 against d59cc02ef6ca68f340c9570e56f7eb71d90e42e7. No blocking finding in this test-only change.

The stronger checks address the old coverage gaps: target-scan counters are checked independently of COUNT/MIN; unsafe fractional, NULL, negative, different-safe and recovery bindings have distinct expected results. The existing CAST/text-warning, nonconstant-derived and 2^53 collision controls remain, and prepared statements/database are cleaned up. No production code or runtime hot path changes.

Also traced EXPLAIN ANALYZE FORCE EXECUTE: FORCE is the grammar form permitting EXECUTE, not an unconditional prepared-plan rebuild flag. Explain and ordinary EXECUTE share parameter initialization, and the DECIMAL uniqueness proof is value-dependent rather than a type-only runtime-cache proof. No evidence that the added Explain statements mask ordinary binding reuse by forcing fresh generations.

Independently checked the actual mo-tester ScriptParser/ResultParser/SqlCommand comparator, not a Python approximation. A lightweight Java harness parsed all 213 commands and 21 regex assertions, accepted the retained healthy plan, and rejected changing only the target scan to 13 blocks / 100000 rows. It also rejected misleading aggregate/different-table metrics and non-adjacent Analyze rows; header-only expected results do not bypass the actual-output regex.

Exact-head CI run 37010990325 completed successfully. Its compose artifact reports this case at 213/213, with zero failures, ignored statements or abnormal statements (3.358 seconds). git diff --check passed and the complete-diff SHA-256 matches the PR description. Reused this real execution evidence; no additional MO build, service or broad UT run was started locally.

Scope: approving the regression coverage, not concluding that the conflicting environment-specific report in #29515 has been explained or that the issue can be closed. The PR already makes that distinction explicitly.

[mergify]

This pull request does not currently match the merge queue conditions, so it cannot be queued from here. The box comes back if it matches again.