PS-10481: Fix range optimizer full table scan for IN() with oversized…#5875
Open
percona-mhansson wants to merge 1 commit intopercona:trunkfrom
Open
PS-10481: Fix range optimizer full table scan for IN() with oversized…#5875percona-mhansson wants to merge 1 commit intopercona:trunkfrom
percona-mhansson wants to merge 1 commit intopercona:trunkfrom
Conversation
… values The range optimizer did not handle the case of search keys being longer than the index's key length. In this case, a search key could be created, and in the case of WHERE clauses with multiple sufficient conditions - either OR or IN conditions - it had to fall back to table scan. For binary collations, this is fine: an equality condition involving a value that wouldn't have fit the column can never match, and so we can safely just ignore it in a disjuntion expression. For other collations, however, a longer sequence in code points can match a shorter one, and there is no upper limit. Fixed by allocating a larger buffer in case the common key creationg fails due to truncation. We allocate as much space as the worst-case scenario and then some, heeding the advice in comment above `strnxfrmlen()`. For full indexes we just render the entire string, and for prefixes a string we the same amount of characters (really code points) as the index's declared key length. Putting the test case in type_varchar since this is ultimately a trait of the VARCHAR type.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
… values
The range optimizer did not handle the case of search keys being longer than the index's key length. In this case, a search key could be created, and in the case of WHERE clauses with multiple sufficient conditions - either OR or IN conditions - it had to fall back to table scan.
For binary collations, this is fine: an equality condition involving a value that wouldn't have fit the column can never match, and so we can safely just ignore it in a disjuntion expression. For other collations, however, a longer sequence in code points can match a shorter one, and there is no upper limit.
Fixed by allocating a larger buffer in case the common key creationg fails due to truncation. We allocate as much space as the worst-case scenario and then some, heeding the advice in comment above
strnxfrmlen(). For full indexes we just render the entire string, and for prefixes a string we the same amount of characters (really code points) as the index's declared key length.Putting the test case in type_varchar since this is ultimately a trait of the VARCHAR type.