MDEV-6657: Poor plan choice for ORDER BY key DESC optimization...bb-10.1-mdev6657

The problem was caused by the following scenario:
- range optimizer picks an index IDX1 which doesn't match the ORDER BY ...
  LIMIT clause.
- test_if_skip_sort_order() decides to switch to index IDX2 which matches
  the ORDER BY ... LIMIT.
- it runs SQL_SELECT::test_quick_select() for the second time to produce
  an quick select for IDX2.
- However, test_quick_select() would figure that full index scan on IDX1
  is still cheaper (its calculations ignore the LIMIT n).

Fixed this by
- passing force_quick_range=true to test_quick_select()
- in test_quick_select, don't consider full index scans if the mentioned
  parameter is true.

Numerous changes in .result files are caused by test_quick_select() being
run after "early/late NULLs filtering" feature has injected NOT NULL
condition.

1 files changed, 1 insertions, 1 deletions

diff --git a/mysql-test/r/subselect_mat.result b/mysql-test/r/subselect_mat.result
index 6cc627ad16c..30b020cbcf6 100644
--- a/mysql-test/r/subselect_mat.result
+++ b/mysql-test/r/subselect_mat.result
@@ -103,7 +103,7 @@ explain extended
 select * from t1i where a1 in (select max(b1) from t2i where b1 > '0' group by b1);
 id	select_type	table	type	possible_keys	key	key_len	ref	rows	filtered	Extra
 1	PRIMARY	t1i	index	NULL	#	18	#	3	100.00	#
-2	MATERIALIZED	t2i	index	it2i1,it2i3	#	9	#	5	100.00	#
+2	MATERIALIZED	t2i	range	it2i1,it2i3	#	9	#	5	100.00	#
 Warnings:
 Note	1003	select `test`.`t1i`.`a1` AS `a1`,`test`.`t1i`.`a2` AS `a2` from `test`.`t1i` where <expr_cache><`test`.`t1i`.`a1`>(<in_optimizer>(`test`.`t1i`.`a1`,`test`.`t1i`.`a1` in ( <materialize> (select max(`test`.`t2i`.`b1`) from `test`.`t2i` where (`test`.`t2i`.`b1` > '0') group by `test`.`t2i`.`b1` ), <primary_index_lookup>(`test`.`t1i`.`a1` in <temporary table> on distinct_key where ((`test`.`t1i`.`a1` = `<subquery2>`.`max(b1)`))))))
 select * from t1i where a1 in (select max(b1) from t2i where b1 > '0' group by b1);