The cause for this bug is that MariaDB 5.3 still processes derived tables (subqueries in the FROM clause)
by fully executing them during the parse phase. This will be remedied by MWL#106 once merged into the
main 5.3.
The assert statement is triggered when MATERIALIZATION is ON for EXPLAIN EXTENDED for derived
tables with an IN subquery as follows:
- mysql_parse calls JOIN::exec for the derived table as if it is regular execution (not explain).
- When materialization is ON, this call goes all the way to subselect_hash_sj_engine::exec, which
creates a partial match engine because of NULL presence.
- In order to proceed with normal execution, the hash_sj engine substitutes itself with the created
partial match engine.
- After the parse phase it turns out that this execution was part of EXPLAIN EXTENDED, which in
turn calls Item_cond::print -> ... -> Item_subselect::print, which calls engine->print().
Since subselect_hash_sj_engine::exec substituted the current Item_subselect engine with a
partial match engine, eventually we call its ::print() method. However the partial match engines are
designed only for execution, hence there is no implementation of this print() method.
Possible solutions:
1. best solution - merge MWL#106, then derived tables will not be materialized at all during EXPLAIN,
and we will never execute subqueries inside derived tables during EXPLAIN.
2. Detect somehow that subselect_hash_sj_engine::exec is called during EXPLAIN. This is hard to do
as upper JOIN::exec doesn't set the SELECT_DESCRIBE flag.
3. Implement both print() methods of the partial match engines to call subselect_hash_sj_engine::print().
4. Remove the assert, and wait for (1) above.
Analsys:
The cause for this bug is that MariaDB 5.3 still processes derived tables (subqueries in the FROM clause)
by fully executing them during the parse phase. This will be remedied by MWL#106 once merged into the
main 5.3.
The assert statement is triggered when MATERIALIZATION is ON for EXPLAIN EXTENDED for derived hash_sj_ engine: :exec, which :print, which calls engine->print(). hash_sj_ engine: :exec substituted the current Item_subselect engine with a
tables with an IN subquery as follows:
- mysql_parse calls JOIN::exec for the derived table as if it is regular execution (not explain).
- When materialization is ON, this call goes all the way to subselect_
creates a partial match engine because of NULL presence.
- In order to proceed with normal execution, the hash_sj engine substitutes itself with the created
partial match engine.
- After the parse phase it turns out that this execution was part of EXPLAIN EXTENDED, which in
turn calls Item_cond::print -> ... -> Item_subselect:
Since subselect_
partial match engine, eventually we call its ::print() method. However the partial match engines are
designed only for execution, hence there is no implementation of this print() method.
Possible solutions: hash_sj_ engine: :exec is called during EXPLAIN. This is hard to do hash_sj_ engine: :print( ).
1. best solution - merge MWL#106, then derived tables will not be materialized at all during EXPLAIN,
and we will never execute subqueries inside derived tables during EXPLAIN.
2. Detect somehow that subselect_
as upper JOIN::exec doesn't set the SELECT_DESCRIBE flag.
3. Implement both print() methods of the partial match engines to call subselect_
4. Remove the assert, and wait for (1) above.