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/sql/opt_range.cc b/sql/opt_range.cc
index 2616e044025..7a584eed742 100644
--- a/sql/opt_range.cc
+++ b/sql/opt_range.cc
@@ -3056,7 +3056,7 @@ int SQL_SELECT::test_quick_select(THD *thd, key_map keys_to_use,
     param.alloced_sel_args= 0;
 
     /* Calculate cost of full index read for the shortest covering index */
-    if (!head->covering_keys.is_clear_all())
+    if (!force_quick_range && !head->covering_keys.is_clear_all())
     {
       int key_for_use= find_shortest_key(head, &head->covering_keys);
       double key_read_time= head->file->keyread_time(key_for_use, 1, records) +