cockroachdb / cockroachdb/cockroach

opt: execution fallback for catastrophically bad plan

Open
#150,267 0 comments 0 reactions 0 assignees View on GitHub
C-enhancement O-support P-3 T-sql-queries
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.