cockroachdb / cockroachdb/cockroach
opt: canary plan changes before committing to them
- Dominant language
- Go
- Stars
- 32.5k
- Forks
- 4.1k
- PR merge metrics
- PR metrics pending
Description
We have canary statistics (#150015) which roll out new table stats to a subset of queries before promoting them. We could apply the same pattern to plan changes.
When the optimizer would switch from one plan to another (e.g., due to stats changes or crossing the generic/custom threshold), instead of switching all executions at once, canary the new plan on a fraction of executions and compare actual performance metrics. Only promote the new plan if it doesn't regress.
This would reduce the risk of plan regressions that are hard to predict from cost estimates alone.
Related: #150015, #156817, #172169
Epic CRDB-57272
Jira issue: CRDB-65316
Contributor guide
Research direction
Start by reading the canary statistics work in #150015 and the related optimizer issues #156817 and #172169 to understand the existing rollout pattern and plan-switching cases. Define how a new plan is sampled, how actual performance is compared, and what promotion criteria prevent regressions; done means the design is implemented and validated for statistics changes and generic/custom threshold transitions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- databases
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100