MDEV-31479: Inconsistency between MRR and SQL layer costs can cause p…

…oor query plan (Same as TODO-3938: best_access_path shows negative costs for mrr=on) best_access_path() assumes that quick select cost includes (quick->rows/TIME_FOR_COMPARE) as a cost of checking the attached part of the WHERE condition. It calls adjust_quick_cost() to subtract addition from quick's cost. The problem was that DS-MRR cost formula didn't include this cost. For very large tables, adjust_quick_cost() would produce a negative cost which would cause assert in debug build or bad query plan choice in release builds. Approved-by: Monty <[email protected]>
MariaDB · Jun 14, 2023 · 0e2e70c · 0e2e70c
1 parent 841e905
commit 0e2e70c
Showing 1 changed file with 3 additions and 0 deletions.
diff --git a/sql/multi_range_read.cc b/sql/multi_range_read.cc
@@ -2006,6 +2006,9 @@ bool DsMrr_impl::get_disk_sweep_mrr_cost(uint keynr, ha_rows rows, uint flags,
  /* Total cost of all index accesses */
  index_read_cost= primary_file->keyread_time(keynr, 1, rows);
  cost->add_io(index_read_cost, 1 /* Random seeks */);
+
+ cost->cpu_cost+= (rows2double(rows) / TIME_FOR_COMPARE +
+ MULTI_RANGE_READ_SETUP_COST);
  return FALSE;
 }