1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-29 05:21:33 +03:00

MDEV-23811: With large number of indexes optimizer chooses an inefficient plan

This bug could manifest itself for a query with WHERE condition containing
top level OR formula such that each conjunct contained a single-range
condition supported by the same index. One of these range conditions must
be fully covered by another range condition that is used later in the OR
formula. Additionally at least one of these condition should be ANDed with
a sargable range condition supported by a different index.

There were several attempts to fix related problems for OR conditions after
the backport of range optimizer code from MySQL (commit
0e19f3e36f). Unfortunately the first of these
fixes contained typo remained unnoticed until recently. This typo bug led
to rejection of valid range accesses. This patch fixed this typo bug.
The fix revealed another two bugs: one in a constructor for SEL_ARG,
the other in the function tree_or(). Both are fixed in this patch.
This commit is contained in:
Igor Babaev
2020-11-09 13:51:32 -08:00
parent 1404f3bea7
commit bea84aefb0
5 changed files with 194 additions and 4 deletions

View File

@ -1852,6 +1852,9 @@ SEL_ARG::SEL_ARG(SEL_ARG &arg) :Sql_alloc()
next_key_part=arg.next_key_part;
max_part_no= arg.max_part_no;
use_count=1; elements=1;
next= 0;
if (next_key_part)
++next_key_part->use_count;
}
@ -9597,10 +9600,11 @@ key_or(RANGE_OPT_PARAM *param, SEL_ARG *key1,SEL_ARG *key2)
if (!tmp->next_key_part)
{
if (key2->use_count)
SEL_ARG *key2_next= key2->next;
if (key2_shared)
{
SEL_ARG *key2_cpy= new SEL_ARG(*key2);
if (key2_cpy)
if (!key2_cpy)
return 0;
key2= key2_cpy;
}
@ -9621,7 +9625,7 @@ key_or(RANGE_OPT_PARAM *param, SEL_ARG *key1,SEL_ARG *key2)
Move on to next range in key2
*/
key2->increment_use_count(-1); // Free not used tree
key2=key2->next;
key2=key2_next;
continue;
}
else