release-21.1: opt: fix bug in histogram estimation code for multi-column spans #76557
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport 1/1 commits from #76486.
/cc @cockroachdb/release
Release justification: Low risk, high benefit change to existing functionality
This commit fixes a bug in the histogram estimation code, which could
cause the optimizer to think that an index scan produced 0 rows, when
in fact it produced a large number. This was due to an inaccurate assumption
in the histogram filtering code that if a span had an exclusive boundary,
the upper bound of the span was excluded from the histogram. However, this
failed to account for the fact that we support constraining a histogram with
multi-column spans, and we can select different column offsets to use to
constrain the histogram. The assumption above is only valid if the column
offset corresponds to the last column in the span key. This logic has now
been fixed.
Fixes #76485
Release note (performance improvement): Fixed a bug in the histogram estimation
code that could cause the optimizer to think a scan of a multi-column index
would produce 0 rows, when in fact it would produce many rows. This could cause
the optimizer to choose a suboptimal plan. This bug has now been fixed, making
it less likely for the optimizer to choose a suboptimal plan when multiple
multi-column indexes are available.