perf(plan): make outer and anti join planning fail-closed by aptend · Pull Request #27934 · matrixorigin/matrixone

aptend · 2026-09-01T03:48:46Z

What type of PR is this?

Which issue(s) this PR fixes:

Related to #26768

What this PR does / why we need it:

Owns the fail-closed outer/ANTI closure and the single RFC v6 design record for #27914, #27915, and #27934. The RFC and implementation are reviewed as one exact-head unit and are now aligned at in-progress.

Applies LEFT-to-ANTI only for proved direct nullable-side NULL rejection.
Applies preserved-side and nullable-side outer associations only under structural legality guards.
Recalculates statistics only when LEFT-to-ANTI actually changes the tree; unchanged queries keep the old hot path.
Makes ANTI cardinality explicitly follow the logical preserved/matching sides after a physical right-ANTI child swap, including the primary-key proof.
Adds conservative ANTI cardinality and exact shuffle-lineage reuse.
Adds the cohort rollback outerAntiPlanning=1 for every rule owned by this PR.
Adds public SQL positive-path result and typed-plan coverage for LEFT-to-ANTI and both associations, including matched, unmatched, duplicate, and NULL rows.

Exact-head validation:

./pkg/sql/plan and ./pkg/sql/compile: PASS.
Public SQL TestOuterAndAntiJoinRewritesPreserveSQLResults: PASS.
Right-ANTI swap regression executes determineBuildAndProbeSide -> swapJoinChildren -> reCalcNodeStatsAfterSwap in enabled and rollback modes: PASS; estimated output never exceeds the 10-row preserved input.
Scoped golangci-lint: 0 issues; git diff --check: clean.
Same-host pinned planner benchmark versus origin/main@c46d897e96: control p50 +0.2% / p95 -0.3%; admitted p50 maximum +8.4% / p95 maximum +5.0%; allocation maximum +0.8%; no reachable-node increase.
TPC-DS 1 TiB Q80 on exact head: PASS twice in 313.818s and 317.652s; 100 rows; baseline-identical SHA-256 67cc97acf391bb464285c8e42615cafdd5b1b21a24893bf7e243c73495dcd661; 16,634,768,895 rows read; 580,640,176,980 bytes scanned; zero spill bytes; second fresh-service run had VmHWM=7,337,188 KiB.
TPC-DS 1 TiB Q78 on exact head: PASS in 1275.508s (recorded same-host predecessor: 1364.2s); 100 rows; predecessor-identical SHA-256 aba289da41554fc62aae876cb7ef4b0af4d5650a6f5bec4b9bd0190aa00730fe; 5,544,181,980 rows read; 185,472,581,988 bytes scanned; 9,618,441,088-byte StatsArray memory; 295,955,082,891 spill bytes; fresh-service process VmHWM=17,174,460 KiB.
Same-runner TPCH 1 TiB: candidate 2h17m26s, main control 2h17m27s.

The exact benchmark command, fixture, per-sample raw output, p50/p95 calculations, and current-head TPC-DS statement/resource records are attached in the review response.

qodo-code-review · 2026-09-01T03:48:50Z

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 →

XuPeng-SH

Reviewed exact head 013e579. I did not find another concrete implementation defect in the legality proofs, and the focused planner tests plus additional UPDATE/DELETE/lateral diagnostics pass, but two required gates are still missing:

[blocking][correctness evidence] The claimed public positive-path coverage is absent. pkg/tests/issues/left_join_anti_rewrite_test.go only executes coalesce(r.id, 0) IS NULL and json_object(r.id, 1) IS NULL. Both are deliberately fail-closed cases that must remain LEFT joins, so no black-box test actually executes the new LEFT-to-ANTI path. The outer-association tests likewise invoke helpers on hand-built nodes and do not prove that real SQL reaches either rule or preserves results. This suite would stay green if every positive rewrite became unreachable. Please add public SQL/result regressions for the positive ANTI rewrite and both outer-association rules, including matched, unmatched, duplicate, and NULL rows; pair the result oracle with a typed plan-shape assertion or an independently equivalent/reference query. This is also the validation contract stated in related issue #26768.
[blocking][performance evidence] This performance PR has no exact-head before/after evidence. It adds an unconditional whole-plan anti-rewrite traversal and recursive stats recalculation to every query, adds two more recursive outer-rule traversals in the normal join-ordering path, changes cardinality for all ANTI joins, and changes shuffle-key selection. Green UT/BVT establishes functional compatibility but not planner CPU/latency, target benefit, or workload no-regression. Please attach reproducible same-environment before/after planner metrics and representative target/control plan/runtime evidence (including the TPC-DS target and TPCH no-regression control required by #26768, or an explicitly agreed smaller gate) to the PR body.

aunjgr

Request changes on exact head 013e579bdb1305bd7e48751c0ff1b4de9d2a24c7.

This implementation still fails the mandatory design-first gate. This split alone changes more than 500 non-generated production lines in outer/anti join rewriting, cardinality, build/probe ordering, and shuffle selection, and it materially affects the optimizer hot path. The design contract explicitly applies to the complete feature/refactor and is not waived by splitting implementation PRs.

The series design PR #27930 was closed unmerged with changes requested; no exact revision has an independent approval or accepted in-progress status. A PR-body description is not a stable versioned design decision record. Restore and approve the complete series design first, including rule composition/order, semantic guards, observability/rollback, plan-quality budgets, and the counterexample matrix, then request implementation review against that accepted revision.

aptend · 2026-09-01T09:38:04Z

Performance evidence update for the TPCH no-regression control:

The dedicated 129 AP run tested exact PR head 013e579bdb1305bd7e48751c0ff1b4de9d2a24c7.
The workflow TPCH collect-and-compare performance gate passed: https://github.com/matrixorigin/mo-auto-test/actions/runs/33476183550
TPCH 1T end-to-end case wall time was 2h17m26s, versus 2h17m27s in the immediately preceding same-runner main control (34fb54084c): https://github.com/matrixorigin/mo-auto-test/actions/runs/33409113128
1G was identical (74s); 10G differed by +1s. No TPCH 1T regression was observed.

I added the reproducible run links, exact revisions, and scale timings to the PR body. This addresses the TPCH control portion of the performance feedback; it does not claim that the separate TPC-DS target/planner-overhead or correctness-evidence gates are closed.

XuPeng-SH

Deep re-review of exact head e987af7bd9fde1bb9d903af9f594131a773ce4c7 against current main@c46d897e9645b80178568ef0783dd8e99e527222. This head does close three prior findings: no-op queries no longer trigger full stats recalculation, outerAntiPlanning now owns the complete rollback cohort, and public SQL reaches all three positive rewrites. Substantive CI is green and git diff --check is clean. The current head is still not approvable for the following independent blockers.

[P1][performance/cost correctness] Right-ANTI physical swapping makes the new cardinality estimate use the wrong side. ReCalcNodeStats passes physical child[0] as leftStats to estimateAntiJoinOutcnt (stats.go:1226-1235), and antiJoinLeftKeysArePrimaryKey likewise hard-codes Children[0] as the logical left (stats.go:1491-1524). However, determineBuildAndProbeSide sets IsRightJoin when the logical left is much smaller, swapJoinChildren then flips the children, and reCalcNodeStatsAfterSwap recalculates the swapped tree while correcting only right-SINGLE (stats.go:1457-1481). A focused exact-head regression with a 10-row PK logical-left and a 10,000-row right input takes the normal right-ANTI path and produces Outcnt=5000; an ANTI result cannot exceed its 10-row preserved input. This impossible estimate is present before subsequent shuffle and runtime-filter planning and can poison ancestor costs and distribution decisions. Make post-swap ANTI estimation explicitly use the logical preserved/matching sides, including the PK proof, and add a regression that runs determineBuildAndProbeSide -> swapJoinChildren -> reCalcNodeStatsAfterSwap for enabled and rollback modes.
[design gate] The exact design record explicitly says this candidate is not at its decisive-review state. The RFC is still Status: draft (docs/rfcs/00000000_stats_independent_analytic_plan_rewrites.md:1), lines 29-33 require the final exact candidate to advance to in-progress, and the Ready gate at lines 491-498 requires the unique MORPC allocation and all implementation/evidence gates to be closed. The PR body and latest author comment both say the cumulative MORPC allocation against still-open #27756 is intentionally unresolved. That is a real cross-branch compatibility gate, not merely a label mismatch; resolve it on the final rebased candidate and make the committed RFC describe that exact state.
[performance acceptance] The body does not provide the auditable evidence required by this PR's own RFC. The planner summary omits p95, reachable-node counts, exact commands/raw artifacts, and per-case results, so the 5% control and 15%/25% admitted budgets cannot be independently checked. Q80 has one wall time and digest but no same-environment baseline or rows/bytes, peak memory, and spill bytes; Q78 has a runtime/plan claim but no terminal result/digest, baseline, or resource profile. The TPCH same-runner links are useful and close that control only. Attach the missing exact-head artifacts and target resource evidence rather than treating green UT/BVT as a planner-performance pass.

Validation note: I proved blocker 1 with a temporary package-local regression on the exact head; it failed with 5000 is not less than or equal to 10. The temporary test and staged macOS native library were removed after the run, leaving the review worktree clean.

aptend · 2026-09-02T06:38:31Z

On the MORPC point, I disagree that concurrent use of the next number on unmerged branches is a P1 defect in this PR.

MORPC versions are cumulative integration numbers allocated against the merge base, not durable reservations made by open branches. Two unmerged heads cannot coexist in a rolling deployment: only code that has actually reached the target branch can be built into that deployment. The repository-safe rule is therefore straightforward: the first PR merged owns the next number; every later PR rebases and moves its gates/tests/generated artifacts to the next contiguous number before it can merge. GitHub's up-to-date-base/CI requirements enforce that integration point, and the renumbered head receives normal re-review.

Blocking semantic review of every open PR until all other open users of the provisional number merge serializes unrelated work without improving mixed-version safety. The unsafe state would be merging a stale later head without rebasing; that is already prohibited. Please evaluate this PR's protocol fallback contract and predecessor test independently of other unmerged branch-local numbers. I will handle the mechanical final allocation on the merge-order rebase, whoever lands first.

aptend · 2026-09-02T07:35:05Z

Addressed the review findings on exact head 630a4f9f083083d7e316f8984f02374c0e3ef4e4.

Right-ANTI physical swap

Commit 8e9d2ba938 makes ANTI estimation take explicit logical preserved/matching node IDs. After a physical right-ANTI swap, recalculation uses physical child 1 as the logical preserved side and physical child 0 as the matching side; the primary-key proof follows the same mapping. BlockNum also comes from the preserved side.

The regression exercises the real sequence determineBuildAndProbeSide -> swapJoinChildren -> reCalcNodeStatsAfterSwap with a 10-row logical-left PK input and a 10,000-row matching input:

enabled: Outcnt=5, BlockNum=2;
rollback: Outcnt=0, BlockNum=2;
both assert Outcnt <= 10.

Focused, full planner/compile, public SQL, scoped lint, and git diff --check validation all pass.

Design state

RFC v6 is in-progress on this exact head. Its implementation, rollback cohort, public semantic matrix, and measured budgets now describe the code being reviewed.

Auditable planner corpus

Base was matrixorigin/matrixone@c46d897e9645b80178568ef0783dd8e99e527222; candidate production code was aptend/matrixone@8e9d2ba938 (the following 630a4f9f08 commit is documentation-only). Host was an Intel i7-11700, Linux amd64, Go 1.26.4. Both revisions used one pinned CPU:

taskset -c 15 ./.agents/skills/mo-dev/scripts/mo-cgo-test \
  -run=^$ -bench=BenchmarkOuterAntiPlanning -benchmem \
  -benchtime=1s -count=5 -cpu=1 ./pkg/sql/plan

The fixture SHA-256 is 94feab2b0622f2cf0b07d2539ce8ba4e027729115ade606022f7b2fbbd0391ab. It parses and calls BuildPlan for four fixed SQL shapes (control INNER, LEFT-to-ANTI, preserved-side association, nullable-side association) and reports distinct nodes reachable from every query step.

Raw samples below are ns/op, nodes/op, B/op, allocs/op:

base control:    78438,4,59755,607  78485,4,59757,607  77501,4,59757,607  78761,4,59757,607  79099,4,59757,607
head control:    78486,4,59757,607  78620,4,59759,607  78673,4,59758,607  78512,4,59757,607  78872,4,59757,607
base LEFT-ANTI:  85199,5,62287,653  85444,5,62284,653  84909,5,62283,653  85237,5,62287,653  85349,5,62284,653
head LEFT-ANTI:  86222,4,61933,657  86417,4,61933,657  86459,4,61934,657  86271,4,61933,657  86306,4,61932,657
base preserved:  112960,6,91304,941 105251,6,91304,941 104125,6,91304,941 105815,6,91304,941 108129,6,91304,941
head preserved:  114539,6,92000,968 113226,6,92000,968 118654,6,92000,968 114691,6,92000,968 114939,6,92000,968
base nullable:   113366,6,95968,972 109009,6,95968,972 110948,6,95968,972 109099,6,95968,972 109350,6,95968,972
head nullable:   111266,6,95768,966 117172,6,95768,966 117956,6,95768,966 117234,6,95768,966 117221,6,95768,966

p95 is nearest-rank (maximum of five samples):

case	p50 delta	p95 delta	B/op delta	reachable nodes
control INNER	+0.2%	-0.3%	0.0%	4 -> 4
LEFT-to-ANTI	+1.3%	+1.2%	-0.6%	5 -> 4
preserved-side association	+8.4%	+5.0%	+0.8%	6 -> 6
nullable-side association	+7.2%	+4.0%	-0.2%	6 -> 6

These are within the RFC's fixed control/admitted p50, p95, and allocation budgets; no case gains a reachable node.

Exact-head TPC-DS 1 TiB evidence

Environment: the same local NVMe dataset tpcds_1t, isolated endpoint 127.0.0.1:6001, 16 logical CPUs / 31 GiB RAM, automatic merge disabled through mo_ctl, and aggregate/join/sort spill thresholds all 134217728 bytes.

Q80 completed twice on exact head with identical results and resources:

client wall: 313.818 s and 317.652 s; second statement duration 317631855883 ns, status Success;
result: 100 rows, SHA-256 67cc97acf391bb464285c8e42615cafdd5b1b21a24893bf7e243c73495dcd661, exactly matching the recorded full-suite result;
rows read: 16634768895; bytes scanned: 580640176980;
second-run StatsArray memory: 911588379 bytes; spill bytes: 0;
second fresh-service process high-water RSS: VmHWM=7337188 KiB (includes the service baseline, caches, and query).

Raw statement_info projection:

01a06104-c725-7b9e-940b-8ae375d4080f Success 317631855883 16634768895 580640176980 100 [6,40245614398816,911588379.000,0,0,8188,0,108,1386088.5577,0,0,0,0,0,0,63331249347583,1]

Q78 exact-head terminal/resource evidence:

wall: 1275494705446 ns (1275.495 s statement / 1275.508 s client wall), status Success;
result: 100 rows, SHA-256 aba289da41554fc62aae876cb7ef4b0af4d5650a6f5bec4b9bd0190aa00730fe; byte-for-byte identical to the recorded successful predecessor result;
rows read: 5544181980; bytes scanned: 185472581988;
StatsArray memory: 9618441088 bytes; spill bytes: 295955082891;
fresh-service process high-water RSS from /proc/<pid>/status: VmHWM=17174460 KiB (includes the service baseline, caches, and query).

Raw statement_info projection:

01a060ee-4cf6-72f2-be79-21fcb1f4a83c Success 1275494705446 5544181980 185472581988 100 [6,52421910611235,9618441088.000,0,0,6039,0,113,1859524.1894,0,0,0,0,0,295955082891,13058189089169,1]

The recorded same-host predecessor completed in 1364.2 s with the same rows/bytes and result, 296069795084 spill bytes, a 10600599944-byte recorded generation peak, and a 9175617392-byte memory-domain live peak. The current exact head is 6.5% faster with comparable/slightly lower tracked resources. The earlier full-suite baseline timed out at 1800 seconds.

The exact-head Q78 plain plan contains three ANTI joins and REUSE on both following joins. No query was run concurrently and automatic merge remained disabled.

aptend · 2026-09-02T08:11:30Z

RFC-only follow-up 8ac5fe82192320c5b0200ff36f1a6d27890c1ba6 records the scalar current-CN topology contract implemented in #27915: shuffle-crossing lineages are rejected, final physical placement is validated, and an unproved topology removes both optional message endpoints before execution. The #27934 production code and its planner/TPC-DS evidence are unchanged; the template body now links this current exact RFC revision.

XuPeng-SH

Deep re-review of exact head 8ac5fe82192320c5b0200ff36f1a6d27890c1ba6 against base c46d897e9645b80178568ef0783dd8e99e527222, including the increment after my prior requested-changes head e987af7bd9fd, the real RIGHT-ANTI physical sequence, the complete RFC v6 contract, main-branch drift, planner-cost fields, rollback, and counterexamples.

The prior blockers are closed:

RIGHT-ANTI now passes explicit logical preserved/matching node IDs after physical child swapping. The PK proof follows that same mapping, output is clamped to the preserved cardinality, and BlockNum comes from the preserved side. The regression executes determineBuildAndProbeSide -> swapJoinChildren -> reCalcNodeStatsAfterSwap in enabled and rollback modes.
RFC v6 is in-progress and treats the cumulative MORPC number as final-rebase integration metadata with a real predecessor boundary, not as a semantic hard-coded reservation.
The exact-base/head planner corpus reports raw p50/p95, allocations, and reachable-node counts within the stated budgets. Exact-head Q80/Q78 terminal results, digests, rows/bytes, memory, spill, and HWM are attached, with the TPCH control retained.

I rechecked ordinary LEFT-ANTI, swapped RIGHT-ANTI, complete/partial/right-only PK, rollback, zero/non-finite estimate clamping, join cost/hash-map direction, physical call ordering, and the fail-closed RFC boundaries. I found no additional correctness, performance, lifecycle, or design blocker. Current main has no post-base overlap in the touched planner/RFC paths, and substantive exact-head CI is terminal green.

Validation note: the exact worktree's focused local test invocation was blocked before compilation by the absent cgo/libmo.dylib; I do not count that as a local pass. This approval relies on source inspection, the exact-head regression/CI, and the attached reproducible evidence.

aptend · 2026-09-02T14:53:50Z

Updated exact head to bb34f62071 by merging current main e0a8738651. The production merge was clean; main introduced a package-local test helper with the same name, so the duplicate was removed and both test suites now use the shared helper.

Validation on the merged head:

full ./pkg/sql/plan
all focused outer/anti rewrite, associativity, shuffle-reuse, cardinality, rollback, and current-main subquery-control tests
public TestOuterAndAntiJoinRewritesPreserveSQLResults

All passed with the repository CGo test wrapper.

aunjgr

Reviewed exact head bb34f62 against merge base e0a8738.

The v6 RFC is now in-progress and the implementation matches its ordered, fail-closed contracts. The prior objective gaps are closed: no-op plans skip recursive stats recalculation; outerAntiPlanning owns the complete rollback cohort; public SQL reaches LEFT-to-ANTI and both outer-association rules with duplicate/NULL result oracles; physical right-ANTI cardinality explicitly maps logical preserved/matching sides after child swapping and clamps output to the preserved input; and the planner/target/control evidence is recorded against fixed budgets. A range-diff across the newest-main merge shows all 19 semantic commits unchanged, and exact-head CI is terminal green.

I found no remaining correctness, compatibility, lifecycle, boundedness, or performance gate blocker.

mergify · 2026-09-03T01:47:51Z

Merge Queue Status

✅ Entered queue — 2026-09-03 01:47 UTC · Rule: main · triggered by rule Automatic queue on approval for main
❌ Checks failed · in-place
🚫 Left the queue — 2026-09-03 02:30 UTC · at e9e26995d6718934fe0e86025fe4c32ece7ca68c

This pull request spent 42 minutes 45 seconds in the queue, with no time running CI.

Waiting for

All conditions

Reason

The merge conditions cannot be satisfied due to failing checks

Failing checks:

Hint

You may have to fix your CI before adding the pull request to the queue again.
If you update this pull request, to fix the CI, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio queue comment.

Requeued — the merge queue status continues in this comment ↓.

mergify · 2026-09-03T07:31:27Z

Merge Queue Status

✅ Entered queue — 2026-09-03 07:30 UTC · Rule: main · triggered by rule Automatic queue on approval for main
🟠 Checks running · in-place
🚫 Left the queue — 2026-09-03 07:41 UTC · at a3519ff1001cacd927aae25e4c1b7721f3b09b88

This pull request spent 10 minutes 9 seconds in the queue, with no time running CI.

Waiting for

All conditions

Reason

Pull request #27934 has been dequeued

Pull request from fork cannot be queued. This pull request comes from a fork, and Mergify needs the author's permission to update its branch.

The author needs to enable "Allow edits from maintainers" on this pull request.

Failing checks:

🟠 Matrixone CI / SCA Test on Linux/arm64 (job log)
🟠 Matrixone CI / UT Test on Ubuntu/x86 (job log)
🟠 Matrixone UT Coverage / UT Coverage on Ubuntu/x86 (job log)

Hint

You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it.
If you do update this pull request, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio queue comment.

Tick the box to put this pull request back in the merge queue (same as @mergifyio queue).

Requeue this pull request

aptend requested review from XuPeng-SH and aunjgr as code owners September 1, 2026 03:48

aptend temporarily deployed to ci September 1, 2026 03:48 — with GitHub Actions Inactive

aptend temporarily deployed to ci September 1, 2026 03:49 — with GitHub Actions Inactive

aptend mentioned this pull request Sep 1, 2026

perf(plan): expose safe subquery predicates before join costing #27915

Merged

7 tasks

mergify Bot added the kind/enhancement label Sep 1, 2026

matrix-meow added the size/XL Denotes a PR that changes [1000, 1999] lines label Sep 1, 2026

aptend temporarily deployed to ci September 1, 2026 03:57 — with GitHub Actions Inactive

aptend temporarily deployed to ci September 1, 2026 04:35 — with GitHub Actions Inactive

XuPeng-SH requested changes Sep 1, 2026

View reviewed changes

aunjgr requested changes Sep 1, 2026

View reviewed changes

aptend requested a review from fengttt as a code owner September 1, 2026 09:59

aptend had a problem deploying to ci September 1, 2026 10:00 — with GitHub Actions Error

aptend temporarily deployed to ci September 1, 2026 10:00 — with GitHub Actions Inactive

aptend requested review from XuPeng-SH and aunjgr September 1, 2026 10:00

mergify Bot added the kind/documentation Improvements or additions to documentation label Sep 1, 2026

aptend had a problem deploying to ci September 1, 2026 10:07 — with GitHub Actions Error

aptend temporarily deployed to ci September 1, 2026 10:40 — with GitHub Actions Inactive

aptend requested review from XuPeng-SH and aunjgr September 2, 2026 03:32

aptend temporarily deployed to ci September 2, 2026 03:38 — with GitHub Actions Inactive

aptend temporarily deployed to ci September 2, 2026 04:17 — with GitHub Actions Inactive

XuPeng-SH requested changes Sep 2, 2026

View reviewed changes

aptend added 2 commits September 2, 2026 14:41

fix(plan): preserve anti cardinality after physical swap

8e9d2ba

docs(rfc): advance analytic rewrites to in progress

630a4f9

aptend had a problem deploying to ci September 2, 2026 07:04 — with GitHub Actions Error

aptend temporarily deployed to ci September 2, 2026 07:04 — with GitHub Actions Inactive

aptend temporarily deployed to ci September 2, 2026 07:12 — with GitHub Actions Inactive

aptend requested a review from XuPeng-SH September 2, 2026 07:35

aptend temporarily deployed to ci September 2, 2026 07:47 — with GitHub Actions Inactive

docs(rfc): define scalar filter topology fallback

8ac5fe8

aptend temporarily deployed to ci September 2, 2026 07:55 — with GitHub Actions Inactive

XuPeng-SH approved these changes Sep 2, 2026

View reviewed changes

Merge remote-tracking branch 'origin/main' into pr27934-design-revision

bb34f62

aunjgr approved these changes Sep 3, 2026

View reviewed changes

mergify Bot and others added 2 commits September 3, 2026 01:47

Merge branch 'main' into perf/tpcds-outer-anti-robustness

e9e2699

Merge branch 'main' into perf/tpcds-outer-anti-robustness

5542172

Merge branch 'main' into perf/tpcds-outer-anti-robustness

a3519ff

Navigation Menu

Uh oh!

perf(plan): make outer and anti join planning fail-closed - #27934

perf(plan): make outer and anti join planning fail-closed#27934
XuPeng-SH merged 23 commits into
matrixorigin:mainfrom
aptend:perf/tpcds-outer-anti-robustness

aptend commented Sep 1, 2026 •

edited

Loading

Uh oh!

qodo-code-review Bot commented Sep 1, 2026

Uh oh!

XuPeng-SH left a comment

Uh oh!

aunjgr left a comment

Uh oh!

aptend commented Sep 1, 2026

Uh oh!

XuPeng-SH left a comment

Uh oh!

aptend commented Sep 2, 2026

Uh oh!

aptend commented Sep 2, 2026

Uh oh!

aptend commented Sep 2, 2026

Uh oh!

XuPeng-SH left a comment

Uh oh!

aptend commented Sep 2, 2026

Uh oh!

aunjgr left a comment

Uh oh!

mergify Bot commented Sep 3, 2026 •

edited

Loading

Uh oh!

mergify Bot commented Sep 3, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

aptend commented Sep 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What type of PR is this?

Which issue(s) this PR fixes:

What this PR does / why we need it:

Uh oh!

qodo-code-review Bot commented Sep 1, 2026

Qodo reviews are paused for this user.

Uh oh!

XuPeng-SH left a comment

Choose a reason for hiding this comment

Uh oh!

aunjgr left a comment

Choose a reason for hiding this comment

Uh oh!

aptend commented Sep 1, 2026

Uh oh!

XuPeng-SH left a comment

Choose a reason for hiding this comment

Uh oh!

aptend commented Sep 2, 2026

Uh oh!

aptend commented Sep 2, 2026

Right-ANTI physical swap

Design state

Auditable planner corpus

Exact-head TPC-DS 1 TiB evidence

Uh oh!

aptend commented Sep 2, 2026

Uh oh!

XuPeng-SH left a comment

Choose a reason for hiding this comment

Uh oh!

aptend commented Sep 2, 2026

Uh oh!

aunjgr left a comment

Choose a reason for hiding this comment

Uh oh!

mergify Bot commented Sep 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merge Queue Status

Reason

Hint

Uh oh!

mergify Bot commented Sep 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merge Queue Status

Reason

Hint

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

aptend commented Sep 1, 2026 •

edited

Loading

mergify Bot commented Sep 3, 2026 •

edited

Loading

mergify Bot commented Sep 3, 2026 •

edited

Loading