MDEV-39440: Failed to match the stats from replay context with the optimizer stats:#5064
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a regression test for MDEV-39440 and modifies sql/opt_range.cc to move the optimizer context recording logic. A review comment correctly identifies that this change could lead to the use of uninitialized max_index_blocks and max_row_blocks variables when the row count is invalid, suggesting they be initialized to zero to prevent recording garbage data.
bsrikanth-mariadb
force-pushed
the
13.0-MDEV-39440-stats-matching-failed-from-replay-context
branch
3 times, most recently
from
58cc38e to
a745b59
Compare
"throwed"? Is "altering an index" required at all? Please change the commit message to be more descriptive. |
| } | ||
| } | ||
|
|
||
| if (range && (rec= param->thd->opt_ctx_recorder)) |
There was a problem hiding this comment.
Can you elaborate about the case where range==NULL. When does that happen?
Is it correct that we will not make a record in the optimizer context in that case?
There was a problem hiding this comment.
range is now initialized to null. And if the rows is not HA_POS_ERROR, then it will never be null.
From all the tests that I ran it was never null though.
bsrikanth-mariadb
force-pushed
the
13.0-MDEV-39440-stats-matching-failed-from-replay-context
branch
from
a745b59 to
ab86775
Compare
bsrikanth-mariadb
changed the title
bsrikanth-mariadb
changed the title
…timizer stats The problem is that handler->multi_range_read_info_const() call in check_quick_select() returned rows equal to HA_POS_ERROR, both during context capture and replay. However, we never stored the ranges info into the context when rows=HA_POS_ERROR. However, during replay, we try to infuse stats for the given range, and since no match was found in the context, we produced a warning. Solution is to store range_info for all the ranges even when they get HA_POS_ERROR number of rows.
bsrikanth-mariadb
force-pushed
the
13.0-MDEV-39440-stats-matching-failed-from-replay-context
branch
from
ab86775 to
40514d9
Compare
2 participants
The problem is that handler->multi_range_read_info_const() call in check_quick_select() returned rows equal to HA_POS_ERROR, both during context capture and replay. However, we never stored the ranges info into the context when rows=HA_POS_ERROR. However, during replay, we try to infuse stats for the given range, and since no match was found in the context, we produced a warning.
Solution is to store range_info for all the ranges even when they get HA_POS_ERROR number of rows.