MDEV-41252: partial join cost Assertion failure in recompute_join_cost_with_limit() - #5802
Open
bsrikanth-mariadb wants to merge 1 commit into
Open
bsrikanth-mariadb wants to merge 1 commit into
bsrikanth-mariadb wants to merge 1 commit into
Conversation
…t_with_limit() recompute_join_cost_with_limit() computes the cost of the first table's partial join as best_read*fraction - pos->read_time*fraction. When the two costs are nearly equal and large (e.g. with a huge optimizer_scan_setup_cost, or when fraction is close to 1), the two products are rounded independently. The difference can then be a small negative number whose magnitude exceeds the absolute DBL_EPSILON tolerance used by the debug assertion, even though it is only a floating-point rounding artifact. Fix: scale the assertion tolerance with the magnitude of the operands (DBL_EPSILON * pos->read_time * fraction). Negative values are still clamped to 0.0 as before. Add test cases to optimizer_crash.test, one with a very large optimizer_scan_setup_cost and optimizer_join_limit_pref_ratio=1, and one with a large LIMIT on a 30000-row table.
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.
recompute_join_cost_with_limit() computes the cost of the first table's partial join as best_readfraction - pos->read_timefraction. When the two costs are nearly equal and large (e.g. with a huge optimizer_scan_setup_cost, or when fraction is close to 1), the two products are rounded independently. The difference can then be a small negative number whose magnitude exceeds the absolute DBL_EPSILON tolerance used by the debug assertion, even though it is only a floating-point rounding artifact.
Fix: scale the assertion tolerance with the magnitude of the operands (DBL_EPSILON * pos->read_time * fraction). Negative values are still clamped to 0.0 as before.
Add test cases to optimizer_crash.test, one with a very large optimizer_scan_setup_cost and optimizer_join_limit_pref_ratio=1, and one with a large LIMIT on a 30000-row table.