Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11
-
None
-
None
Description
I've hit this when doing patch #2 for MDEV-30218:
https://github.com/MariaDB/server/commit/678f2220cc25b3495f1f16fe2732e49a0cd120f8
EXPLAIN in subselect2.result shows "ref|filter":
1 PRIMARY t3 ref|filter PRIMARY,FFOLDERID_IDX,CMFLDRPARNT_IDX FFOLDERID_IDX|CMFLDRPARNT_IDX 34|35 test.t3.PARENTID 1 (29%) Using where; Using rowid filter
|
The nature of the patch hints that this access should have been eq_ref.
MDEV-30218.
Debugging, one can see that best_access_path() considers eq_ref on that index.
Optimizer Trace also shows:
{
|
"access_type": "eq_ref",
|
"index": "FFOLDERID_IDX",
|
"rowid_filter_key": "CMFLDRPARNT_IDX",
|
"rows": 1,
|
"cost": 15.444,
|
"chosen": true
|
},
|
Attachments
Activity
This code in create_ref_for_key() considers the index non-unique:
=> else if (!((keyparts == keyinfo->user_defined_key_parts &&
|
(
|
(key_flags & (HA_NOSAME | HA_NULL_PART_KEY)) == HA_NOSAME ||
|
/* Unique key and all keyparts are NULL rejecting */
|
((key_flags & HA_NOSAME) && keyparts == not_null_keyparts)
|
)) ||
|
/* true only for extended keys */
|
(keyparts > keyinfo->user_defined_key_parts &&
|
MY_TEST(key_flags & HA_EXT_NOSAME) &&
|
keyparts == keyinfo->ext_key_parts)
|
) ||
|
null_ref_key)
|
{
|
/* Must read with repeat */
|
j->type= null_ref_key ? JT_REF_OR_NULL : JT_REF;
|
j->ref.null_ref_key= null_ref_key;
|
j->ref.null_ref_part= null_ref_part;
|
}
|
while this code in best_access_path considers the index unique:
if ((key_flags & (HA_NOSAME | HA_EXT_NOSAME)) && // (1)
|
(!(key_flags & HA_NULL_PART_KEY) || // (2)
|
all_key_parts == notnull_part)) // (3)
|
{
|
=> type= JT_EQ_REF;
|
The index in question:
(gdb) p key_flags & HA_NOSAME$61 = 0(gdb) p key_flags & HA_EXT_NOSAME$62 = 131072(gdb) p keyinfo->name.str$63 = 0x7fff980bab91 "FFOLDERID_IDX"keyinfo->user_defined_key_parts=1keyinfo->usable_key_parts = 1keyinfo->ext_key_parts = 1