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

Bug#51431 Wrong sort order after import of dump file

Browse Source 
The problem is that QUICK_SELECT_DESC behaviour depends
on used_key_parts value which can be bigger than selected
best_key_parts value if an engine supports clustered key.
But used_key_parts is overwritten with best_key_parts
value that prevents from correct selection of index
access method. The fix is to preserve used_key_parts
value for further use in QUICK_SELECT_DESC.
This commit is contained in:
Sergey Glukhov
2010-06-30 17:06:25 +04:00
parent 3b3983a408
commit a6220d8279
3 changed files with 72 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
sql/sql_select.cc
View File

@ -13419,6 +13419,7 @@ test_if_skip_sort_order(JOIN_TAB *tab,ORDER *order,ha_rows select_limit,
uint nr;
key_map keys;
uint best_key_parts= 0;
uint saved_best_key_parts= 0;
int best_key_direction= 0;
ha_rows best_records= 0;
double read_time;
@ -13579,6 +13580,7 @@ test_if_skip_sort_order(JOIN_TAB *tab,ORDER *order,ha_rows select_limit,
{
best_key= nr;
best_key_parts= keyinfo->key_parts;
saved_best_key_parts= used_key_parts;
best_records= quick_records;
is_best_covering= is_covering;
best_key_direction= direction;
@ -13665,8 +13667,15 @@ test_if_skip_sort_order(JOIN_TAB *tab,ORDER *order,ha_rows select_limit,
*/
}
}
used_key_parts= best_key_parts;
order_direction= best_key_direction;
/*
saved_best_key_parts is actual number of used keyparts found by the
test_if_order_by_key function. It could differ from keyinfo->key_parts,
thus we have to restore it in case of desc order as it affects
QUICK_SELECT_DESC behaviour.
*/
used_key_parts= (order_direction == -1) ?
saved_best_key_parts : best_key_parts;
}
else
DBUG_RETURN(0);