database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-08-05 13:16:09 +03:00
Code Activity

MDEV-35164: optimizer_join_limit_pref_ratio: assertion when the ORDER BY table becomes constant

Browse Source 
Assertion failure has happened due to this scenario:

A query was ran with optimizer_join_limit_pref_ratio=1.
The query had "ORDER BY t1.col LIMIT N".
The optimizer set join->limit_shortcut_applicable=1.
Then, table t1 was marked as constant.
The code in choose_query_plan() still set join->limit_optimization_mode=1
which caused the optimizer to only consider t1 as the first non-const table.
But t1 was already put into the join prefix as the constant table.
The optimizer couldn't produce any join order at all and crashed.

Fixed by not searching for shortcut plan if ORDER BY table is a constant.
We will not try to do sorting anyway in this case (and LIMIT short-cutting
will be done for any join order).
This commit is contained in:
Sergei Petrunia
2024-10-18 15:42:05 +03:00
parent 0540eac05c
commit a68e74b5a4
3 changed files with 81 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
sql/sql_select.cc
View File

@@ -9306,8 +9306,18 @@ choose_plan(JOIN *join, table_map join_tables)
double limit_cost= DBL_MAX;
POSITION *limit_plan= NULL;
/* First, build a join plan that can short-cut ORDER BY...LIMIT */
if (join->limit_shortcut_applicable && !join->emb_sjm_nest)
/*
First, build a join plan that can short-cut ORDER BY...LIMIT.
Do it if
(1) The SELECT in query makes it possible to do short-cutting for
some table TBL.
(2) We are optimizing the whole JOIN, not a semi-join nest
(3) The table TBL has not been marked as constant (in this case,
ORDER BY LIMIT will be optimized away)
*/
if (join->limit_shortcut_applicable && // (1)
!join->emb_sjm_nest && // (2)
!(join->sort_by_table->map & join->const_table_map)) //(3)
{
bool res;
Json_writer_object wrapper(join->thd);