matrixorigin / matrixorigin/matrixone

[Subtask]: Preserve current MatrixOne numeric semantics in Sirius Substrait offload

Open
#28,968 0 comments 0 reactions 1 assignee Claimed by @aunjgr View on GitHub
kind/subtask needs-triage
Dominant language
Go
Stars
1.9k
Forks
311
Avg merge
1d 3h
Merged PRs (30d)
768

Description

## Parent Issue

Parent issue: #28966. Related predecessor compatibility coverage: #26159.

## Detail of Subtask

Independently close current MatrixOne numeric/type compatibility gaps in Sirius
Substrait offload. MO can produce Decimal256 intermediates; the current bridge
accepts decimal precision up to 38. Inventory the exact current-main canonical
TPC-H plan failures before selecting a fix; this issue is not a claim that every
query fails or that wide decimals are the only remaining incompatibility.

The embedded-runtime migration may proceed without this work, but all 22 SF1
and SF10 queries must actually execute through Sirius (both MO-reader and
direct-TAE input) before Flight is retired. This is a hard release blocker for
#28966, not a reason to weaken eligibility or count CPU fallback as success.

## Describe implementation you've considered

1. Capture current MO canonical plans, bound overloads, logical/result metadata,
and the exact unsupported types/operators in Q1-Q22.
2. Design value- and metadata-preserving numeric lowering/execution across MO's
exporter, Sirius planning, GPU operators, and result reconstruction.
3. Define exact scale, rounding, overflow, division and NULL behavior before
implementation. Keep transport/embedding work out of this issue.
4. Reuse counterexamples from #26159 and the existing exporter/decimal suites;
verify current-main changes rather than assuming historical benchmark plans.

No SQL rewrites to sidestep the problem, decimal-to-float coercion, unchecked
narrowing, relaxed result comparison, or silent native fallback are acceptable.
Normal agreed floating-point comparison tolerance does not waive exact decimal
semantics. PR #28941 has a separate SUBSTRING metadata admission adjustment;
do not duplicate it or treat it as wide-decimal support.

## Additional information

- [ ] Current-main plan/type failure inventory
- [ ] Separate approved numeric design and concrete PR breakdown
- [ ] Exact positive, boundary, overflow/division, NULL and metadata tests
- [ ] Real GPU execution and native-MO equality for all 22 SF1/SF10 queries
- [ ] Matching embedded MO-reader and direct-TAE results with GPU streams=2

The numeric PR count is deliberately separate from #28966's ten migration PRs.
No numeric implementation is included in the migration foundation work.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.