Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.3.10, 5.5.65, 10.3.20
-
None
Description
This is from the same customer issue as MDEV-21243.
It is possible to construct a join query which will use full table scan for one of the tables, even if there is a possible range access for that table.
I'm not sure if table definitions are public so I will not post the details in public until we've figured a general case to demonstrate the issue.
The issue is reproducible on 10.3.{10,20} and 5.5.65. Not reproducible on 5.2.14
Symptoms:
The first range optimizer call constructs the range access.
The problem shows up here in make_join_select
/* |
We plan to scan all rows.
|
Check again if we should use an index.
|
We could have used an column from a previous table in
|
the index if we are using limit and this is the first table
|
|
|
(1) - Don't switch the used index if we are using semi-join
|
LooseScan on this table. Using different index will not
|
produce the desired ordering and de-duplication.
|
*/
|
|
|
if (!tab->table->is_filled_at_execution() && |
!tab->loosescan_match_tab && // (1) |
((cond && (!tab->keys.is_subset(tab->const_keys) && i > 0)) ||
|
(!tab->const_keys.is_clear_all() && i == join->const_tables &&
|
join->unit->select_limit_cnt <
|
join->best_positions[i].records_read &&
|
!(join->select_options & OPTION_FOUND_ROWS))))
|
The if-branch is taken, inside it, SQL_SELECT::test_quick_select is called which doesn't construct the range access anymore (can't use multiple equalities?) and this is how we end up with a full table scan.
Attachments
Issue Links
- relates to
-
-
- In Progress
-
-
-
- Closed
-