Currently SQL_BIG_RESULT is checked only at compile time.
However, additional optimizations may take place after
this check that change the sort method from 'filesort'
to sorting via index. As a result the actual plan
executed is not the one specified by the SQL_BIG_RESULT
hint. Similarly, there is no such test when executing
EXPLAIN, resulting in incorrect output.
The patch corrects the problem by testing for
SQL_BIG_RESULT both during the explain and execution
phases.
mysql-test/r/bdb.result:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- updated sql_big_result testcase
mysql-test/r/group_by.result:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- test case with MyISAM
mysql-test/r/innodb.result:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- updated sql_big_result testcase
mysql-test/r/innodb_mysql.result:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- test case with InnoDB
mysql-test/r/myisam.result:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- updated sql_big_result testcase
mysql-test/t/group_by.test:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- test case with MyISAM
mysql-test/t/innodb_mysql.test:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- test case with InnoDB
sql/sql_select.cc:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- When SQL_BIG_RESULT is specified, disable the optimization performed
at execution/explain time that decides to use an index instead
of filesort.
Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
- moved an InnoDB dependent test to the appropriate file
mysql-test/r/innodb_mysql.result:
Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
- moved an InnoDB dependent test to the appropriate file
mysql-test/r/join_outer.result:
Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
- moved an InnoDB dependent test to the appropriate file
mysql-test/t/innodb_mysql.test:
Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
- moved an InnoDB dependent test to the appropriate file
mysql-test/t/join_outer.test:
Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
- moved an InnoDB dependent test to the appropriate file
The crash was caused by invalid sequence of handler::** calls:
ha_smth->index_init();
ha_smth->index_next_same(); (2)
(2) is an invalid call as it was not preceeded by any 'scan setup' call
like index_first() or index_read(). The cause was that QUICK_SELECT::reset()
didn't "fully reset" the quick select- current QUICK_RANGE wasn't forgotten,
and quick select might attempt to continue reading the range, which would
result in the above mentioned invalid sequence of handler calls.
5.x versions are not affected by the bug - they already have the missing
"range=NULL" clause.
mysql-test/r/innodb_mysql.result:
Testcase for BUG#21077
mysql-test/t/innodb_mysql.test:
Testcase for BUG#21077
sql/opt_range.h:
BUG#21077: Possible crash caused by invalid sequence of handler::* calls:
- Make QUICK_SELECT::reset() really reset the quick select
into macbook.gmz:/Users/kgeorge/mysql/work/B17212-5.0-opt
mysql-test/r/innodb_mysql.result:
Merge 4.1->5.0 for bug #17212
mysql-test/t/innodb_mysql.test:
Merge 4.1->5.0 for bug #17212
sql/sql_select.cc:
Merge 4.1->5.0 for bug #17212
* don't use join cache when the incoming data set is already ordered
for ORDER BY
This choice must be made because join cache will effectively
reverse the join order and the results will be sorted by the index
of the table that uses join cache.
mysql-test/r/innodb_mysql.result:
Bug #17212 results not sorted correctly by ORDER BY when using index
* Test suite for the bug
mysql-test/t/innodb_mysql.test:
Bug #17212 results not sorted correctly by ORDER BY when using index
* Test suite for the bug
sql/sql_select.cc:
Bug #17212 results not sorted correctly by ORDER BY when using index
* don't use join cache when the incoming data set is already sorted
Moved the InnoDB related tests to innodb_mysql
mysql-test/r/group_min_max.result:
Moved innodb related tests out of group_min_max
mysql-test/r/innodb_mysql.result:
Moved innodb related tests out of group_min_max
mysql-test/t/group_min_max.test:
Moved innodb related tests out of group_min_max
mysql-test/t/innodb_mysql.test:
Moved innodb related tests out of group_min_max
Moved the InnoDB related test from func_group.test to innodb_mysql.test
mysql-test/r/func_group.result:
Moved a test to innodb_mysql
mysql-test/r/innodb_mysql.result:
moved a test to innodb_mysql
mysql-test/t/func_group.test:
Moved a test to innodb_mysql
mysql-test/t/innodb_mysql.test:
Moved a test to innodb_mysql
The bug was as follows: When merge_key_fields() encounters "t.key=X OR t.key=Y" it will
try to join them into ref_or_null access via "t.key=X OR NULL". In order to make this
inference it checks if Y<=>NULL, ignoring the fact that value of Y may be not yet known.
The fix is that the check if Y<=>NULL is made only if value of Y is known (i.e. it is a
constant).
TODO: When merging to 5.0, replace used_tables() with const_item() everywhere in merge_key_fields().
mysql-test/r/innodb_mysql.result:
Testcase for BUG16798
mysql-test/t/innodb_mysql.test:
Testcase for BUG16798
sql/sql_select.cc:
BUG#16798: Inapplicable ref_or_null query plan and bad query result on random occasions
In merge_key_fields() don't call val->is_null() if the value of val is not known.
Use files innodb_mysql.[test|result] instead.
mysql-test/t/innodb.test:
This file is to be used by Innobase only.
mysql-test/r/innodb_mysql.result:
New BitKeeper file ``mysql-test/r/innodb_mysql.result''
Use this file instead of innodb.result.
mysql-test/t/innodb_mysql.test:
New BitKeeper file ``mysql-test/t/innodb_mysql.test''
Use this file instead of innodb.test.
