I wonder if this might have been caused by the MDEV-27582 fix. I reasoned that we are free to use an internal ordering of KEY a(a ASC, id ASC) instead of KEY a(a ASC, id DESC) for the secondary index. If this query is executed as a covering index scan, then perhaps we should revert the current MDEV-27582 fix
diff --git a/storage/innobase/dict/dict0dict.cc b/storage/innobase/dict/dict0dict.cc
|
--- a/storage/innobase/dict/dict0dict.cc
|
+++ b/storage/innobase/dict/dict0dict.cc
|
@@ -2649,8 +2649,7 @@ dict_index_build_internal_non_clust(
|
|
if (!indexed[field->col->ind] || index->is_spatial()) {
|
dict_index_add_col(new_index, table, field->col,
|
- field->prefix_len,
|
- field->descending);
|
+ field->prefix_len);
|
}
|
}
|
|
and fix MDEV-27582 in a different way, by changing the way the FULLTEXT INDEX code is reading the FTS_DOC_ID index inside InnoDB.
I wonder if this might have been caused by the
MDEV-27582fix. I reasoned that we are free to use an internal ordering of KEY a(a ASC, id ASC) instead of KEY a(a ASC, id DESC) for the secondary index. If this query is executed as a covering index scan, then perhaps we should revert the currentMDEV-27582fixdiff --git a/storage/innobase/dict/dict0dict.cc b/storage/innobase/dict/dict0dict.cc
--- a/storage/innobase/dict/dict0dict.cc
+++ b/storage/innobase/dict/dict0dict.cc
@@ -2649,8 +2649,7 @@ dict_index_build_internal_non_clust(
if (!indexed[field->col->ind] || index->is_spatial()) {
dict_index_add_col(new_index, table, field->col,
- field->prefix_len,
- field->descending);
+ field->prefix_len);
}
}
and fix
MDEV-27582in a different way, by changing the way the FULLTEXT INDEX code is reading the FTS_DOC_ID index inside InnoDB.