cockroachdb / cockroachdb/cockroach

opt: canary plan changes before committing to them

Open
#172,170 0 comments 0 reactions 0 assignees View on GitHub
A-generic-query-plans A-sql-optimizer C-enhancement T-sql-queries
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.