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, 7 insertions, 1 deletions

diff --git a/sql/sql_select.cc b/sql/sql_select.cc
index 05c88a5f534..860f0cd346c 100644
--- a/sql/sql_select.cc
+++ b/sql/sql_select.cc
@@ -20168,7 +20168,7 @@ test_if_skip_sort_order(JOIN_TAB *tab,ORDER *order,ha_rows select_limit,
                                          (tab->join->select_options &
                                           OPTION_FOUND_ROWS) ?
                                          HA_POS_ERROR :
-                                         tab->join->unit->select_limit_cnt,0,
+                                         tab->join->unit->select_limit_cnt,TRUE,
                                          TRUE) <= 0;
           if (res)
           {
@@ -20286,6 +20286,12 @@ check_reverse_order:
       */
       if (!table->covering_keys.is_set(best_key))
         table->disable_keyread();
+      else
+      {
+        if (!table->key_read)
+          table->enable_keyread();
+      }
+
       if (!quick_created)
       {
         if (select)                  // Throw any existing quick select