mirror of
https://github.com/MariaDB/server.git
synced 2025-07-30 16:24:05 +03:00
Fix for bug lp:944706, task MDEV-193
The patch enables back constant subquery execution during query optimization after it was disabled during the development of MWL#89 (cost-based choice of IN-TO-EXISTS vs MATERIALIZATION). The main idea is that constant subqueries are allowed to be executed during optimization if their execution is not expensive. The approach is as follows: - Constant subqueries are recursively optimized in the beginning of JOIN::optimize of the outer query. This is done by the new method JOIN::optimize_constant_subqueries(). This is done so that the cost of executing these queries can be estimated. - Optimization of the outer query proceeds normally. During this phase the optimizer may request execution of non-expensive constant subqueries. Each place where the optimizer may potentially execute an expensive expression is guarded with the predicate Item::is_expensive(). - The implementation of Item_subselect::is_expensive has been extended to use the number of examined rows (estimated by the optimizer) as a way to determine whether the subquery is expensive or not. - The new system variable "expensive_subquery_limit" controls how many examined rows are considered to be not expensive. The default is 100. In addition, multiple changes were needed to make this solution work in the light of the changes made by MWL#89. These changes were needed to fix various crashes and wrong results, and legacy bugs discovered during development.
This commit is contained in:
@ -159,6 +159,10 @@ The following options may be given as the first argument:
|
||||
Enable the event scheduler. Possible values are ON, OFF,
|
||||
and DISABLED (keep the event scheduler completely
|
||||
deactivated, it cannot be activated run-time)
|
||||
--expensive-subquery-limit=#
|
||||
The maximum number of rows a subquery may examine in
|
||||
order to be executed during optimization and used for
|
||||
constant optimization
|
||||
--expire-logs-days=#
|
||||
If non-zero, binary logs will be purged after
|
||||
expire_logs_days days; possible purges happen at startup
|
||||
@ -885,6 +889,7 @@ delayed-queue-size 1000
|
||||
div-precision-increment 4
|
||||
engine-condition-pushdown FALSE
|
||||
event-scheduler OFF
|
||||
expensive-subquery-limit 100
|
||||
expire-logs-days 0
|
||||
external-locking FALSE
|
||||
extra-max-connections 1
|
||||
|
Reference in New Issue
Block a user