Date: Mon, 01 Nov 2010 15:15:25 -0000
3272 Roy Lyseng 2010-11-01
Bug#52068: Optimizer generates invalid semijoin materialization plan
When MaterializeScan semijoin strategy was used and there were one
or more outer dependent tables before the semijoin tables, the scan
over the materialized table was not properly reset for each row of
the prefix outer tables.
Example: suppose we have a join order:
ot1 SJ-Mat-Scan(it2 it3) ot4
Notice that this is called a MaterializeScan, even though there is an
outer table ahead of the materialized tables. Usually a MaterializeScan
has the outer tables after the materialized table, but this is
a special (but legal) case with outer dependent tables both before and
after the materialized table.
For each qualifying row from ot1, a new scan over the materialized
table must be set up. The code failed to do that, so all scans after
the first one returned zero rows from the materialized table.
- Make Mrr_ordered_index_reader() save the rowid across scan interruptions
Also
- Fix compiler warning for setup_buffer_sizes()
- Add commented key_copy/key_restore for better handling of a similar issue
with index record being destroyed by scan interruption (which causes
incorrect evaluation of pushed index condition later on).
- Fixed problem with oqgraph and 'make dist'
Note that after this merge we have a problem show in join_outer where we examine too many rows in one specific case (related to BUG#57024).
This will be fixed when mwl#128 is merged into 5.3.
Fix MySQL BUG#52344 - Subquery materialization: Assertion if subquery in on-clause of outer join
Original fix and comments from Oysten, adjusted for the different
subquery optimization in MariaDB.
"
Problem: If tables of an outer join are constant tables,
the associated on-clause will be evaluated in the optimization
phase. If the on-clause contains a query that is to be
executed with subquery materialization, this will not work
since the infrastructure for such execution is not yet set up.
Solution: Do not evaluate on-clause in optimization phase if
is_expensive() returns true for this clause. This is how the
problem is currently avoided for where-clauses. This works
because, Item_in_subselect::is_expensive_processor returns true
if query is to be executed with subquery materialization.
"
In addition, after MWL#89, in MariaDB if the IN-EXISTS strategy
is chosen, the in-to-exists predicates are insterted after
join_read_const_table() is called, resulting in evaluation of
the subquery without the in-to-exists predicates.
Open issues:
- A better fix for #57688; Igor is working on this
- Test failure in index_merge_innodb.test ; Igor promised to look at this
- Some Innodb tests fails (need to merge with latest xtradb) ; Kristian promised to look at this.
- Failing tests: innodb_plugin.innodb_bug56143 innodb_plugin.innodb_bug56632 innodb_plugin.innodb_bug56680 innodb_plugin.innodb_bug57255
- Werror is disabled; Should be enabled after merge with xtradb.
Analysis:
The send_data method of the result sink class used to collect
data statistics about materialized subqueries incorrectly assumed
that duplicate rows are removed prior to calling send_data. As
a result the collected statistics was wrong, which resulted in
an incorrect maximal number of keys in the Ordered_key buffer.
Solution:
Try to insert each row into the materialized temp table before
collecting statistics, and if the insertion results in a duplicate
row, do not count the current row.
Registration of pointer change if we assign it to other pointer which should be identical after statement execution (PS/SP).
mysql-test/r/subselect.result:
Test suite.
mysql-test/t/subselect.test:
Test suite.
sql/sql_class.cc:
The procedure of the pointer registration.
sql/sql_class.h:
The procedure of the pointer registration.
sql/sql_lex.cc:
Registration of pointer change if we assign it to other pointer which should be identical after statement execution (PS/SP).
mysql-test/r/heap_btree.result:
Test of index over bit firld in hash table.
mysql-test/r/heap_hash.result:
Test of index over bit firld in hash table.
mysql-test/t/heap_btree.test:
Test of index over bit firld in hash table.
mysql-test/t/heap_hash.test:
Test of index over bit firld in hash table.
storage/heap/ha_heap.cc:
Adding bit field support for heap tables.
storage/heap/hp_create.c:
Adding bit field support for heap tables.
storage/heap/hp_hash.c:
Adding bit field support for heap tables.
The bug happened when BKA join algorithm used an incremental buffer
and some of the fields over which access keys were constructed
- were allocated in the previous join buffers
- were non-nullable
- belonged to inner tables of outer joins.
For such fields an offset to the field value in the record is saved
in the postfix of the record, and a zero offset indicates that the value
is null. Before the key using the field value is constructed the
value is read into the corresponding field of the record buffer and
the null bit is set for the field if the offset is 0. However if
the field is non-nullable the table->null_row must be set to 1
for null values and to 0 for non-null values to ensure proper reading
of the value from the record buffer.
The condition that was supposed to check whether a join table
is an inner table of a nested outer join or semi-join was not
quite correct in the code of the function check_join_cache_usage.
That's why some queries with nested outer joins triggered
an assertion failure.
Encapsulated this condition in the new method called
JOIN_TAB::is_nested_inner and provided a proper code for it.
Also corrected a bug in the code of check_join_cache_usage()
that caused a downgrade of not first join buffers of the
level 5 and 7 to level 4 and 6 correspondingly.
When pushing the condition for a table in the function
JOIN_TAB::make_scan_filter the optimizer must not push
conditions from WHERE if the table is some inner table
of an outer join..
The condition over outer tables extracted from the on expression
for a outer join must be ANDed to the condition pushed to the
first inner table of this outer join only.
Nested outer joins cannot use flat join buffers. So if join_cache_level
is set to 1 then any join algorithm employing join buffers cannot be used
for nested outer joins.
The patch that introduced the new enumeration type Match_flag
for the values of match flags in the records put into join buffers
missed the necessary modifications in JOIN_CACHE::set_match_flag_if_none.
This could cause wrong results for outer joins with on expressions
only over outer tables.
A non-incremental join buffer cannot be used for inner tables of nested
outer joins. That's why when join_cache_level is set to 7 it must
be downgraded to level 6 for the inner tables of nested outer joins.
For the same reason with join_cache_level set to 3 no join buffer is
used for the inner tables of outer joins (we could downgrade it to
level 2, but this level does not support ref access).
Miscalculation of the minimum possible buffer size could trigger
an assert in JOIN_CACHE_HASHED::put_record when if join_buffer_size
was set to the values that is less than the length of one record to
stored in the join buffer.
It happened due to the following mistakes:
- underestimation of space needed for a key in the hash table
(we have to take into account that hash table can have more
buckets than the expected number of records).
- the value of maximum total length of all records stored in
the join buffer was not saved in the field max_used_fieldlength
by the function calc_used_field_length.
- Fixed bug in pagecache_delete_internal() when deleting block that was flushed by another thread (fixed bug when block->next_used was unexpectedly null)
Fixed some using uninitialized memory warnings found by valgrind.
mysql-test/t/information_schema_all_engines-master.opt:
Added options to make slow test run faster
sql/sp.cc:
Fixed valgrind warning.
sql/sql_show.cc:
Fixed valgrind warning.
storage/maria/ma_bitmap.c:
Fixed wrong call parameter to pagecache_unlock_by_link() that caused assert crash in pagecache
storage/maria/ma_pagecache.c:
Fixed possible error in pagecache_wait_lock() when hash_link was not set. (We never hit this issue, but could be possible when two threads updates the same page.
Fixed bug in pagecache_delete_internal() when deleting block that was flushed by another thread (fixed bug when block->next_used was unexpectedly null)
Cleanup: moved pagecache_pthread_mutex_unlock() over comments and asserts to be just before pagecache_fwrite()
