- 10 Feb, 2011 3 commits
-
-
unknown authored
Analysis: The crash in EXPLAIN resulted from an attempt to print the name of the internal temporary table created to compute distinct for the innermost subquery of the test case. Such tables do not have a corresponding TABLE_LIST (table reference), hence the crash. The reason for this was that the subquery was executed as part of constant condition evaluation before EXPLAIN attempts to print the table name. During the subquery execution, the subquery JOIN_TAB and its table are substituted by a temporary table in make_simple_join. Solution: Similar to the analogous case for other Items than the IS NULL function, do not evaluate expensive constant conditions.
-
unknown authored
Fixed LP BUG#714808 Assertion `outer_lookup_keys <= outer_record_count' Analysis: The function best_access_path() computes the number or records as follows: ... if (rec < MATCHING_ROWS_IN_OTHER_TABLE) rec= MATCHING_ROWS_IN_OTHER_TABLE; // Fix for small tables ... if (table->quick_keys.is_set(key)) records= (double) table->quick_rows[key]; else { /* quick_range couldn't use key! */ records= (double) s->records/rec; } Above MATCHING_ROWS_IN_OTHER_TABLE == 10, and s->records == 1, thus we get an estimated 0.1 records. As a result JOIN::get_partial_join_cost() for the outer query computes outer_record_count == 0.1 records, which is meaningless in this context. Solution: Round row count estimates that are < 1 to 1.
-
unknown authored
Fixed a memory leak found by valgrind. The memory leak was a result of JOINs corresponding to subselects in a global ORDER BY of a UNION not being cleaned up because the fake_select of the UNION didn't point down to the subquery select.
-
- 03 Feb, 2011 1 commit
-
-
unknown authored
Adjusted test cases in accordance with the implementation.
-
- 24 Jan, 2011 2 commits
-
-
unknown authored
- fixed incorrect query plans that resulted from emptying the keyuse array with the access methods of the non-modified query plan. - fixed compiler warning.
-
unknown authored
sql/item.cc: Wrapper added. sql/item.h: Wrapper added. sql/mysql_priv.h: Wrap function added. sql/sql_base.cc: Wrap function added. Fix of problem with WHERE consist of alone outer reference field by wrapping it. sql/sql_select.cc: Fix of problem with HAVING consist of alone outer reference field by wrapping it.
-
- 18 Jan, 2011 1 commit
-
-
unknown authored
Analysis: The cause for the failing assert was that between preparation and execution of a DELETE prepared statement, the server reverted back all changes of the item tree. Since the substitution of Item_in_subselect by an Item_in_optimizer was recorded via change_item_tree, thus the rollback of the item tree affected the substitution as well. As a result the execution of the PS called Item_in_subselect::val_int(), which was never supposed to be called. Solution: Replace change_item_tree with assignment. This is OK because the Item objects used for substitution are created in PS memory.
-
- 17 Jan, 2011 2 commits
-
-
unknown authored
Fixed query plans with loose index scan degraded into index scan. Analysis: With MWL#89 subqueries are no longer executed and substituted during the optimization of the outer query. As a result subquery predicates that were previously executed and substituted by a constant before the range optimizer were present as regular subquery predicates during range optimization. The procedure check_group_min_max_predicates() had a naive test that ruled out all queries with subqueries in the WHERE clause. This resulted in worse plans with MWL#89. Solution: The solution is to refine the test in check_group_min_max_predicates() to check if each MIN/MAX argument is referred to by a subquery predicate.
-
unknown authored
Analysis: Close to its end JOIN::optimize() assigns having to tmp_having, and sets the having clause to NULL: tmp_having= having; if (select_options & SELECT_DESCRIBE) { error= 0; DBUG_RETURN(0); } having= 0; At the same time, this query detects an empty result set, and calls return_zero_rows(), which checks the HAVING clause as follows: if (having && having->val_int() == 0) send_row=0; However having has been already set to NULL, so return_zero_rows doesn't check the having clause, hence the wrong result. Solution: Check join->tmp_having in addition to join->having. There is no additional test case, because the failure was in the current regression test.
-
- 13 Jan, 2011 1 commit
-
-
Michael Widenius authored
This fixes the wrong result in tests like compress, join, join_cache, greedy_optimizer and select_pkeycache
-
- 11 Jan, 2011 1 commit
-
-
unknown authored
-
- 05 Jan, 2011 1 commit
-
-
Igor Babaev authored
When stored in a key buffer any varchar field has a length prefix that always takes 2 bytes.
-
- 30 Dec, 2010 1 commit
-
-
Igor Babaev authored
Added a test case for bug #695442 - a duplicate of bug 694092.
-
- 29 Dec, 2010 2 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
The bug was the result of a bad merge maria-5.2-wl21 -> 5.3.
-
- 28 Dec, 2010 3 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
-
Igor Babaev authored
-
- 27 Dec, 2010 3 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
-
Igor Babaev authored
One of the hash functions employed by the BNLH join algorithm calculates the the value of hash index for key value utilizing every byte of the key buffer. To make this calculation valid one has to ensure that for any key value unused bytes of the buffer are filled with with a certain filler. We choose 0 as a filler for these bytes. Added an optional boolean parameter with_zerofill to the function key_copy. If the value of the parameter is TRUE all unused bytes of the key buffer is filled with 0.
-
- 26 Dec, 2010 1 commit
-
-
Igor Babaev authored
-
- 25 Dec, 2010 1 commit
-
-
Igor Babaev authored
-
- 24 Dec, 2010 2 commits
-
-
Igor Babaev authored
In some cases the function make_cond_for_index() was mistaken when detecting index only pushdown conditions for a table: a pushdown condition that was not index only could be marked as such. It happened because the procedure erroneously used the markers for index only conditions that remained from the calls of this function that extracted the index conditions for other tables. Fixed by erasing index only markers as soon as they are need anymore.
-
Igor Babaev authored
-
- 23 Dec, 2010 2 commits
-
-
unknown authored
- Post-review fixes. Intermediate commit to address review point 1.6. - Fixed valgrind warnings
-
Igor Babaev authored
-
- 22 Dec, 2010 1 commit
-
-
Igor Babaev authored
Lifted the limitation that hash join could not be used over varchar fields with non-binary collation.
-
- 21 Dec, 2010 2 commits
-
-
Sergey Petrunya authored
-
Sergey Petrunya authored
- Merge with 5.3-main
-
- 20 Dec, 2010 2 commits
-
-
Sergei Golubchik authored
set thd->password appropriately also for cases when a user was not found.
-
Sergey Petrunya authored
- Fixes for the second fix: take into account case where we don't need to save/restore the scan.
-
- 19 Dec, 2010 2 commits
-
-
Sergey Petrunya authored
Switch from "Disable identical key handling optimization when IndexConditionPushdown is used" approach To an approach where we save/restore index tuple and so can use index condition pushdown.
-
Igor Babaev authored
mwl#21.
-
- 17 Dec, 2010 3 commits
-
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
unknown authored
It was missing from EXTRA_DIST in Makefile.am.
-
- 16 Dec, 2010 3 commits
-
-
Sergey Petrunya authored
-
Sergey Petrunya authored
- Address Monty's review feedback, portion 3
-
Sergey Petrunya authored
- Address Monty's review feedback, portion 2
-