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

Fix for BUG#7331.

Browse Source 
The problem was that when a QUICK_SELECT access method is chosen,
test_if_skip_sort_order() discovered that the index being used
by the quick select will not deliver tuples in sorted order.
In this case test_if_skip_sort_order() tried to change the index
used by the quick select, but it didn't properly set the other
members of the quick select, and especially the range flags of
the ranges in QUICK_SELECT::ranges.

The fix re-invokes the function SQL_SELECT::test_quick_select
to correctly create a valid QUICK_SELECT object.
This commit is contained in:
timour@mysql.com
2005-01-06 10:49:26 +02:00
parent 22639defce
commit a8f8433c9d
3 changed files with 89 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
sql/sql_select.cc
View File

@ -7153,11 +7153,24 @@ test_if_skip_sort_order(JOIN_TAB *tab,ORDER *order,ha_rows select_limit,
}
else
{
select->quick->file->ha_index_end();
select->quick->index= new_ref_key;
select->quick->init();
/*
The range optimizer constructed QUICK_RANGE for ref_key, and
we want to use instead new_ref_key as the index. We can't
just change the index of the quick select, because this may
result in an incosistent QUICK_SELECT object. Below we
create a new QUICK_SELECT from scratch so that all its
parameres are set correctly by the range optimizer.
*/
key_map new_ref_key_map;
new_ref_key_map.clear_all(); /* Force the creation of quick select */
new_ref_key_map.set_bit(new_ref_key); /* only for new_ref_key. */
if (select->test_quick_select(tab->join->thd, new_ref_key_map, 0,
(tab->join->select_options & OPTION_FOUND_ROWS) ?
HA_POS_ERROR : tab->join->unit->select_limit_cnt) <= 0)
DBUG_RETURN(0);
}
ref_key= new_ref_key;
ref_key= new_ref_key;
}
}
/* Check if we get the rows in requested sorted order by using the key */