diff options
author | unknown <timour@askmonty.org> | 2011-08-27 00:40:29 +0300 |
---|---|---|
committer | unknown <timour@askmonty.org> | 2011-08-27 00:40:29 +0300 |
commit | 2df1914791030714196c3d829187891a97be54dc (patch) | |
tree | d24362560b461dbf256a1b427c543610548b28f1 /sql-bench | |
parent | ee28dec85885a1579758d9184ecb63ce810e738f (diff) | |
download | mariadb-git-2df1914791030714196c3d829187891a97be54dc.tar.gz |
Fix bug lp:827416
Analysis:
Constant table optimization of the outer query finds that
the right side of the equality is a constant that can
be used for an eq_ref access to fetch one row from t1,
and substitute t1 with a constant. Thus constant optimization
triggers evaluation of the subquery during the optimize
phase of the outer query.
The innermost subquery requires a plan with a temporary
table because with InnoDB tables the exact count of rows
is not known, and the empty tables cannot be optimzied
way. JOIN::exec for the innermost subquery substitutes
the subquery tables with a temporary table.
When EXPLAIN gets to print the tables in the innermost
subquery, EXPLAIN needs to print the name of each table
through the corresponding TABLE_LIST object. However,
the temporary table created during execution doesn't
have a corresponding TABLE_LIST, so we get a null
pointer exception.
Solution:
The solution is to forbid using expensive constant
expressions for eq_ref access for contant table
optimization. Notice that eq_ref with a subquery
providing the value is still possible during regular
execution.
Diffstat (limited to 'sql-bench')
0 files changed, 0 insertions, 0 deletions