planner: enable fix control 52869 by default to let planner consider IndexMerge when an alternative index exists

[time-and-fate]

What problem does this PR solve?

Issue Number: ref #26764

Problem Summary:

Please see the issue and the doc.

We have been advising users to enable this flag for similar scenarios, and received no bad cases or bug reports. As we encounter this situation more and more often, we think it makes sense to enable this flag by default.

What changed and how does it work?

Set the default value to ON by default, and update the test results.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No need to test

  • I checked and no code files have been changed.

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

Summary by CodeRabbit

• Bug Fixes

  • Enhanced the query planner to select more efficient index merging strategies for certain complex filter conditions.

• Tests

  • Updated test outputs to reflect the optimized query execution plans.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.9958%. Comparing base (47eea3d) to head (b31c8f2).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #63701        +/-   ##
================================================
- Coverage   77.7266%   76.9958%   -0.7308%     
================================================
  Files          1990       1972        -18     
  Lines        551959     553217      +1258     
================================================
- Hits         429019     425954      -3065     
- Misses       122020     127236      +5216     
+ Partials        920         27       -893     

Flag	Coverage Δ
integration	41.4963% <100.0000%> (+1.6945%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
dumpling	60.4888% <ø> (ø)
parser	∅ <ø> (∅)
br	50.0597% <ø> (-13.0338%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR adjusts the default behavior of the skipRangeScanCheck flag in the IndexMerge path generation logic, changing it from false to true when the Fix52869 optimizer fix control is not explicitly enabled. This causes the planner to more readily consider IndexMerge execution plans instead of full table scans with selections.

Changes

Cohort / File(s)	Summary
Planner Logic pkg/planner/core/indexmerge_path.go	Changed the default value of skipRangeScanCheck from false to true under fixcontrol.Fix52869, altering the decision path for IndexMerge consideration.
Test Results tests/integrationtest/r/executor/explain.result, tests/integrationtest/r/planner/core/indexmerge_path.result	Updated query execution plans showing the shift from Selection over TableFullScan patterns to IndexMerge union plans with TableRangeScan and IndexFullScan branches.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

Suggested reviewers

• qw4990
• AilinKid
• hawkingrei
• winoros

Poem

🐰 A flag flips with quiet grace,
IndexMerge takes its rightful place!
Where tables once scanned far and wide,
Now index paths skip, merge, and glide—
Optimization hops along! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description is incomplete and lacks critical details. While it references an issue and mentions enabling a flag by default, the 'Problem Summary' and 'What changed and how does it work?' sections are essentially empty or insufficiently detailed.	Add a clear problem summary explaining why Fix52869 should be enabled by default. Detail the changes made to the code and test files, and explain the expected impact on query planning behavior.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Title check	✅ Passed	The title clearly and specifically describes the main change: enabling fix control 52869 by default to allow the planner to consider IndexMerge when alternative indexes exist, which aligns with the actual changes made to the code.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (2)

pkg/planner/core/indexmerge_path.go (1)

529-533: Document the intentional default asymmetry for Fix52869.

This default is now true here, while ShouldPreferIndexMerge in pkg/planner/core/rule/rule_prune_indexes.go still defaults to false. Please add a brief inline comment explaining why both defaults differ intentionally, to avoid accidental “cleanup” regressions later.

As per coding guidelines, comments SHOULD explain non-obvious intent, constraints, invariants, concurrency guarantees, SQL/compatibility contracts, or important performance trade-offs.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@pkg/planner/core/indexmerge_path.go` around lines 529 - 533, Add a brief
inline comment next to the skipRangeScanCheck assignment (the call to
fixcontrol.GetBoolWithDefault with fixcontrol.Fix52869) that documents the
intentional default asymmetry with ShouldPreferIndexMerge (in
rule_prune_indexes.go) — state that skipRangeScanCheck defaults to true here for
compatibility/perf/regression reasons while ShouldPreferIndexMerge remains
false, and mention the rationale (e.g., backward compatibility or a staged
rollout) so future maintainers do not "clean up" the differing defaults; place
the comment immediately above or beside the skipRangeScanCheck line and
reference Fix52869 and ShouldPreferIndexMerge by name.

tests/integrationtest/r/planner/core/indexmerge_path.result (1)

1007-1032: Add an explicit 52869:off regression case alongside these new defaults.

These updated expectations validate the new default and match the explicit 52869:on section, but there’s no paired assertion for 52869:off on the same query shapes. Adding that would lock down fix-control toggle semantics and prevent silent behavior drift.

Based on learnings: Applies to pkg/planner/** : For planner rule or logical/physical plan changes, perform targeted planner unit tests and update rule testdata when needed.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/integrationtest/r/planner/core/indexmerge_path.result` around lines
1007 - 1032, Add a paired regression case that explicitly asserts the old
behavior under the `52869:off` toggle for the same query shapes shown (the
IndexMerge/IndexRangeScan(Build)/Selection(Probe)/TableRowIDScan plans for the
three example SELECTs). Copy the three new default expectations and create
matching `52869:off` blocks that show the prior plan layout (i.e., the
alternative IndexRangeScan ordering/absence you expect when the feature is off),
ensuring the blocks reference the same query strings and plan nodes (IndexMerge,
IndexRangeScan(Build), Selection(Probe), TableRowIDScan) so the test locks down
both `52869:on` (new defaults) and `52869:off` semantics.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@pkg/planner/core/indexmerge_path.go`:
- Around line 529-533: Add a brief inline comment next to the skipRangeScanCheck
assignment (the call to fixcontrol.GetBoolWithDefault with fixcontrol.Fix52869)
that documents the intentional default asymmetry with ShouldPreferIndexMerge (in
rule_prune_indexes.go) — state that skipRangeScanCheck defaults to true here for
compatibility/perf/regression reasons while ShouldPreferIndexMerge remains
false, and mention the rationale (e.g., backward compatibility or a staged
rollout) so future maintainers do not "clean up" the differing defaults; place
the comment immediately above or beside the skipRangeScanCheck line and
reference Fix52869 and ShouldPreferIndexMerge by name.

In `@tests/integrationtest/r/planner/core/indexmerge_path.result`:
- Around line 1007-1032: Add a paired regression case that explicitly asserts
the old behavior under the `52869:off` toggle for the same query shapes shown
(the IndexMerge/IndexRangeScan(Build)/Selection(Probe)/TableRowIDScan plans for
the three example SELECTs). Copy the three new default expectations and create
matching `52869:off` blocks that show the prior plan layout (i.e., the
alternative IndexRangeScan ordering/absence you expect when the feature is off),
ensuring the blocks reference the same query strings and plan nodes (IndexMerge,
IndexRangeScan(Build), Selection(Probe), TableRowIDScan) so the test locks down
both `52869:on` (new defaults) and `52869:off` semantics.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: d9cb13f3-8a49-497c-93c8-cbc1a46bac6a

📥 Commits

Reviewing files that changed from the base of the PR and between 212ded5 and d32fdb7.

📒 Files selected for processing (3)

• pkg/planner/core/indexmerge_path.go
• tests/integrationtest/r/executor/explain.result
• tests/integrationtest/r/planner/core/indexmerge_path.result

[time-and-fate]

/retest

[time-and-fate]

/retest

[0xPoe]

Thanks!

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 0xPoe, qw4990

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [0xPoe,qw4990]
• pkg/planner/OWNERS [0xPoe,qw4990]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2026-05-07 09:22:20.946205549 +0000 UTC m=+346013.819555521: ☑️ agreed by qw4990.
• 2026-05-07 09:37:53.039942675 +0000 UTC m=+346945.913292647: ☑️ agreed by 0xPoe.