Hi Ole John,
I've finally had time to look into the MRR flag issue as promised. Note:
partition_explicit_pruning.result needs an update.
I suggest you do the following change to your patch (attachment contains
your patch with my suggestions as shown below):
in opt_range.cc:
----------------
@@ -1220,17 +1221,12 @@
}
-void QUICK_RANGE_SELECT::need_sorted_output()
+void QUICK_RANGE_SELECT::need_sorted_output(bool sort)
{
- if (!(mrr_flags & HA_MRR_SORTED))
- {
- /*
- Native implementation can't produce sorted output. We'll have to
- switch to default
- */
- mrr_flags |= HA_MRR_USE_DEFAULT_IMPL;
- }
- mrr_flags |= HA_MRR_SORTED;
+ if (sort)
+ mrr_flags |= HA_MRR_SORTED;
+ else
+ mrr_flags &= ~HA_MRR_SORTED;
}
in sql_select.cc:
-----------------
@@ -23181,9 +23199,22 @@
if (quick_type == QUICK_SELECT_I::QS_TYPE_RANGE &&
!(((QUICK_RANGE_SELECT*)(tab->select->quick))->mrr_flags &
- HA_MRR_USE_DEFAULT_IMPL))
+ (HA_MRR_USE_DEFAULT_IMPL | HA_MRR_SORTED)))
{
- extra.append(STRING_WITH_LEN("; Using MRR"));
+ /*
+ During normal execution of a query, multi_range_read_init() is
+ called to initialize MRR. If HA_MRR_SORTED is set at this
point,
+ multi_range_read_init() for any native MRR implementation will
+ revert to default MRR because they cannot produce sorted
output
+ currently.
+ Calling multi_range_read_init() can potentially be costly,
so it
+ is not done when executing an EXPLAIN. We therefore make the
+ assumption that HA_MRR_SORTED means no MRR. If some MRR native
+ implementation will support sorted output in the future, a
+ function "bool mrr_supports_sorted()" should be added in the
+ handler.
+ */
+ extra.append(STRING_WITH_LEN("; Using MRR"));
}
Attachment: [text/x-patch] 57601-review.diff
