MDEV-39005: Assertion failure on hint-forced Split-Materialized plan#4776
Open
DaveGosselin-MariaDB wants to merge 1 commit into12.3from
Open
MDEV-39005: Assertion failure on hint-forced Split-Materialized plan#4776DaveGosselin-MariaDB wants to merge 1 commit into12.3from
DaveGosselin-MariaDB wants to merge 1 commit into12.3from
Conversation
| b int, | ||
| primary key (groups_20, groups_20_2) | ||
| ) engine=innodb; | ||
| insert into t1 select seq/1000, seq+1, seq from seq_1_to_20000; |
Member
There was a problem hiding this comment.
Do we need 20k rows?
Member
Author
There was a problem hiding this comment.
I'll take another look to see if I can shorten the example. The large row count affects the splitting math and the triggered assertion, but maybe I can force the error with a smaller row count.
Member
Author
There was a problem hiding this comment.
Hi @mariadb-RexJohnston , I was able to reduce the number of rows needed to 10.
Using a hint to force splitting can force the optimizer to choose a split plan that would otherwise be considered invalid. SPLIT_MATERIALIZED(DT) forces splitting, the optimizer must still respect the invariants checked by apply_selectivity_for_table() for what would otherwise be a splitting that would never be chosen naturally. In the attached test case, a derived table DT performs GROUP BY/HAVING and is then joined to t2. With the hint forcing a split, the splitting code can compute a `records` estimate that makes the effective selectivity (`sel`) exceed the bound assumed in apply_selectivity_for_table() (specifically the `use_cond_selectivity > 1` assertion path), i.e. it can exceed: s->table->opt_range_condition_rows / table_records To fix this, when a split is hint-forced, clamp `records` to the unsplit derived cardinality (`spl_opt_info->unsplit_card`). This effectively bounds `records` to: min(unsplit_card, unsplit_card * split_sel) and prevents `sel` from exceeding the range-condition-rows ratio in the assertion.
DaveGosselin-MariaDB
force-pushed
the
12.3-MDEV-39005-split-materialized-assert
branch
from
24fc103 to
e6ef149
Compare
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
2 participants
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.
Using a hint to force splitting can force the optimizer to choose a split plan that would otherwise be considered invalid. SPLIT_MATERIALIZED(DT) forces splitting but the optimizer must still respect the invariants checked by apply_selectivity_for_table() for what would otherwise be a splitting that would never be chosen naturally.
In the attached test case, a derived table DT performs GROUP BY/HAVING and is then joined to t2. With the hint forcing a split, the splitting code can compute a
recordsestimate that makes the effective selectivity (sel) exceed the bound assumed inapply_selectivity_for_table() (specifically the
use_cond_selectivity > 1assertion path), i.e. it can exceed:s->table->opt_range_condition_rows / table_records
To fix this, when a split is hint-forced, clamp
recordsto the unsplit derived cardinality (spl_opt_info->unsplit_card). This effectively boundsrecordsto:min(unsplit_card, unsplit_card * split_sel)
and prevents
selfrom exceeding the range-condition-rows ratio in the assertion.