- 13 Jul, 2011 2 commits
-
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
- 12 Jul, 2011 1 commit
-
-
Sergey Petrunya authored
-
- 11 Jul, 2011 4 commits
-
-
Sergey Petrunya authored
Port of code for: (part of testcase is in mysql-test/t/subquery*.test and will be ported separately) Bug#11766642: crash in Item_field::register_field_in_read_map with view (Former 59793) Prior to the refactoring in this patch, Item_cond_xor behaved partially as an Item_cond and partially as an Item_func. The reasoning behind this was that XOR is currently not optimized (thus should be Item_func instead of Item_cond), but it was planned optimize it in the future (thus, made Item_cond anyway to ease optimization later). Even though Item_cond inherits from Item_func, there are differences between these two. One difference is that the arguments are stored differently. Item_cond stores them in a list while Item_func store them in an args[]. BUG no 45221 was caused by Item_cond_xor storing arguments in the list while users of the objects would look for them in args[]. The fix back then was to store the arguments in both locations. In this bug, Item_cond_xor initially gets two Item_field arguments. These are stored in the list inherited from Item_cond and in args[] inherited from Item_func. During resolution, find_field_in_view() replaces the Item_fields stored in the list with Item_direct_view_refs, but args[] still points to the unresolved Item_fields. This shows that the fix for 45221 was incorrect. The refactoring performed in this patch removes the confusion by making the XOR item an Item_func period. A neg_transformer() is also implemented for Item_func_xor to improve performance when negating XOR expressions. An XOR is negated by negating one of the operands.
-
Igor Babaev authored
Auto-generated names for view field items must be allocated in the statement memory, not in the execution memory of the statement.
-
Sergey Petrunya authored
The cause of the crash is sj_nest->sj_subq_pred->unit->first_select()->item_list contains "stale" items for the second execution. By "stale" I mean that they have item->fixed==FALSE, and they are Item_field object instead of Item_direct_view_ref. The solution is to use sj_nest->sj_subq_pred->unit->first_select()->ref_pointer_array. Surprisingly, that array contains items that are ok. Oracle team has introduced and is using NESTED_JOIN::sj_inner_exprs, but we go without that and always copy the ref_pointer_array.
-
Igor Babaev authored
Missing initialization of the bitmap not_null_tables_cache to 0 in the function Item_func::eval_not_null_tables caused this bug. This function is called indirectly from the function SELECT_LEX::update_used_tables after merging mergeable views and derived tables into the main query. The leaf tables of resulting query may change their bitmap numbers after this merge. That's why the not_null_tables_cache bitmaps must be updated. Due to the bug mentioned above the result of the re-evaluation of the not_null_tables_cache turned out to be incorrect in some cases. This could trigger an invalid conversion of outer joins into inner joins leading to invalid query result sets. Also removed an implicit conversion from int to bool in the function SELECT_LEX::update_used_tables.
-
- 10 Jul, 2011 6 commits
-
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
Igor Babaev authored
The value of THD::used tables should be re-evaluated after merges of views and derived tables into the main query. Now it's done in the function SELECT_LEX::update_used_tables. The re-evaluation of the 'used_table' bitmaps for the items in HAVING, GROUP BY and ORDER BY clauses has been added as well.
-
- 09 Jul, 2011 3 commits
-
-
Sergey Petrunya authored
Semi-join fixes: make COST_VECT objects survive add_io(add_io_cnt=0, add_avg_cost=...) calls without getting NaN in internal fields.
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
- 08 Jul, 2011 9 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
The bug was caused by an incorrect code of the function Item_direct_view_ref::replace_equal_field introduced in the patch for bugs 717577, 724942. The function erroneously returned the wrapped field instead of the Item_direct_view_ref object itself in the cases when no replacement happened. The bug masked two other minor bugs that could result in not quite correct output of the EXPLAIN command for some queries. They were fixed in the patch as well.
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
Sergey Petrunya authored
- Scavenged subquery tests from testcases other than t/subselect*.test and put them into single file
-
Sergey Petrunya authored
- Set the default - Adjust the testcases so that 'new' tests are run with optimizations turned on. - Pull out relevant tests from "irrelevant" tests and run them with optimizations on. - Run range.test and innodb.test with both mrr=on and mrr=off
-
unknown authored
-
unknown authored
The bug itself has been fixed by MWL#89.
-
unknown authored
The bug itself has been fixed by MWL#89.
-
- 07 Jul, 2011 7 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
The offending query returns a wrong result set because the optimizer erroneously eliminated the where condition evaluated it to TRUE. The cause of this wrong transformation was that the flag maybe_null for an inner table of the outer join was not set to TRUE after the table had replaced the wrapping view. Now the function SELECT_LEX::update_used_tables resets the value of the maybe_null flag for each leaf table of the query after all merges of views have been done.
-
unknown authored
The bug itself has been fixed by MWL#89.
-
unknown authored
The bug itself has been fixed by MWL#89.
-
unknown authored
Analysis: This bug is yet another incarnation of the generic problem where optimization of the outer query triggers evaluation of a subquery, and this evaluation performs a destructive change to the subquery plan. Specifically a temp table is created for the DISTINCT operation that replaces the original subquery table. Later, select_describe() attempts to print the table name, however, there is no corresponding TABLE_LIST object to the internal temp table, so we get a crash. Execution works fine because it is not interested in the corresponding TABLE_LIST object (or its name). Solution: Similar to other such bugs, block the evaluation of expensive Items in convert_const_to_int().
-
Igor Babaev authored
-
Igor Babaev authored
The function generate_derived_keys_for_table incorrectly handled the cases when a materialized view or derived table could be accessed by different keys on the same fields if these keys depended on the same tables.
-
- 06 Jul, 2011 4 commits
-
-
unknown authored
Adjust PBXT test results.
-
unknown authored
-
Sergey Petrunya authored
-
Sergey Petrunya authored
- SELECT_LEX::merge_subquery should not set "(*in_subq)->emb_on_expr_nest= derived" for subqueries that are in the ON expressions of semi-joins.
-
- 05 Jul, 2011 4 commits
-
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
Sergey Petrunya authored
-
Sergey Petrunya authored
BUG#803365: Crash in pull_out_semijoin_tables with outer join + semijoin + derived tables in maria-5.3 with WL#106 - Don't perform table pullout out of semi-join nests that have nested outer joins.
-