cockroachdb / cockroachdb/cockroach
opt: execution fallback for catastrophically bad plan
- Dominant language
- Go
- Stars
- 32.5k
- Forks
- 4.1k
- PR merge metrics
- PR metrics pending
Description
**Is your feature request related to a problem? Please describe.**
The optimizer uses statistics to choose a query plan, but sometimes stats are stale or inaccurate due to sampling. As a result, it's possible that the optimizer may choose a plan that is suboptimal. Although we use certain heuristics to prefer plans that are likely to be safe, in some cases we still choose plans that turn out to be catastrophically bad.
**Describe the solution you'd like**
There should be an escape hatch at execution time if we detect that the optimizer has chosen a catastrophically bad plan. For example, if we detect that a scan is reading 100x or 1000x more rows than expected, we could abort the current plan and choose a different one. Ideally, we'd also include some hint that an alternative plan is available before aborting the current plan.
To choose an alternative plan, we could add another field to the cost struct in the optimizer that would contain a "worst case" cost where we assume the estimated stats are wrong and instead use a fixed large value for the row count. The resulting plan could be used as an alternative fallback during execution.
Jira issue: CRDB-52628
Contributor guide
Assessment
This issue has not been assessed yet.