An error occurred fetching the project authors.
- 24 Oct, 2011 1 commit
-
-
Igor Babaev authored
Do not create KEYUSEs for a materialized view over a constant table.
-
- 23 Oct, 2011 1 commit
-
-
Igor Babaev authored
This bug happened because the function Item_cond::eval_not_null_tables erroneously did not initialize the value of not_null_tables_cache.
-
- 22 Oct, 2011 1 commit
-
-
Igor Babaev authored
This bug happened for the queries over multi-table mergeable views because the bitmap TABLE::read_set of the underlying tables were not updated after the views had been merged into the query. Now this bitmaps are updated properly. Also the bitmap TABLE::merge_keys now is updated in prevention of future bugs.
-
- 20 Oct, 2011 3 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
The function JOIN::drop_unused_derived_keys could erroneously set the value of REF::key to 0 for a joined materialized view/derived table in the case when no REF access to the table was used by the query execution plan. This could cause a crash of the server.
-
Igor Babaev authored
This bug happened due to incompleteness of the fix for bug 872735: the occurrences of the fields in the conditions of correlated subqueries were not taken into account when recalculating covering keys bit maps.
-
- 16 Oct, 2011 1 commit
-
-
Igor Babaev authored
This bug manifested itself with queries containing non-correlated IN subqueries over materialized views/derived tables. The bug happened because the code of the function generate_derived_keys did not take into account that the function could be called twice when the optimizer was deciding whether in-exist transformation should be applied.
-
- 14 Oct, 2011 1 commit
-
-
Igor Babaev authored
This bug happened because the maps of covering keys for mergeable derived tables/views was not recalculated after the derived tables/vies had been merged into the main query.
-
- 01 Oct, 2011 1 commit
-
-
Igor Babaev authored
of the 5.3 code line after a merge with 5.2 on 2010-10-28 in order not to allow the cost to access a joined table to be equal to 0 ever. Expanded data sets for many test cases to get the same execution plans as before.
-
- 16 Aug, 2011 1 commit
-
-
Igor Babaev authored
When merging a view / derived table the function SELECT_LEX::merge_subquery incorrectly updated the list SELECT_LEX::leaf_tables. Erroneously it appended the leaf_tables list of the merged object L and then removed the reference to the merged object T from the SELECT_LEX::leaf_tables list. A correct implementation should insert the list L into the SELECT_LEX::leaf_tables list in place of the element of the list that refers to T. The bug could lead to wrong results or even crashes for queries with nested outer joins over views / derived tables.
-
- 12 Aug, 2011 1 commit
-
-
Igor Babaev authored
-
- 11 Aug, 2011 1 commit
-
-
Igor Babaev authored
The method Item_func_isnull::update_used_tables() erroneously did not update cached values stored in the fields used_tables_cache and const_item_cache of the Item_func_isnull objects. As a result the Item_func_isnull::used_tables() returned wrong bitmaps and, as a consequence, push-down predicates could be attached to wrong tables.
-
- 09 Aug, 2011 1 commit
-
-
Igor Babaev authored
Do not optimize derived table for the second time ever.
-
- 21 Jul, 2011 1 commit
-
-
Igor Babaev authored
off by default.
-
- 18 Jul, 2011 1 commit
-
-
Igor Babaev authored
This bug could lead to wrong result sets for a query over a materialized derived table or view accessed by a multi-component key. It happened because the function get_next_field_for_derived_key was supposed to update its argument, and it did not do it.
-
- 17 Jul, 2011 1 commit
-
-
Igor Babaev authored
Also: 1. simplified the code of the function mysql_derived_merge_for_insert. 2. moved merge of views/dt for multi-update/delete to the prepare stage. 3. the list of the references to the candidates for semi-join now is allocated in the statement memory.
-
- 14 Jul, 2011 1 commit
-
-
Igor Babaev authored
The attribute not_null_tables could be calculated incorrectly in the function SELECT_LEX::update_used_tables for queries over views with row items in the WHERE clause. It happened because no implementation of the virtual callback function eval_not_null_tables was provided for the class Item_row. Also slightly optimized the code calculating the value of the maybe_null flag for tables in the function SELECT_LEX::update_used_tables.
-
- 13 Jul, 2011 1 commit
-
-
Igor Babaev authored
The bitmap of used tables must be evaluated for the select list of every materialized derived table / view and saved in a dedicated field. This is also applied to materialized subqueries.
-
- 11 Jul, 2011 1 commit
-
-
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 1 commit
-
-
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.
-
- 08 Jul, 2011 1 commit
-
-
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.
-
- 07 Jul, 2011 2 commits
-
-
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.
-
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.
-
- 02 Jul, 2011 1 commit
-
-
Igor Babaev authored
If no index is used to access a materialized derived table or view then the value of TABLE_REF::key for this table must be (-1).
-
- 01 Jul, 2011 1 commit
-
-
Igor Babaev authored
The function generate_derived_keys_for_table should set the value of the number of keys for the derived table to 0 before it starts generating key definitions for the table. It's important as the function can be called twice by the optimizer for a derived table if the query contains a subquery to which the IN-EXIST transformation is applicable. Fixed a valgrind complain.
-
- 30 Jun, 2011 1 commit
-
-
Igor Babaev authored
If the expression for a derived table contained a clause LIMIT 0 SELECT from such derived table incorrectly returned a non-empty set. Fixed by ensuring JOIN::do_send_rows to be updated after the call of st_select_lex_unit::set_limit that sets the value of JOIN::unit->select_limit_cnt.
-
- 29 Jun, 2011 1 commit
-
-
Igor Babaev authored
Due to this bug in the function generate_derived_keys_for_table some key definitions to access materialized derived tables or materialized views were constructed with invalid info for their key parts. This could make the server crash when it optimized queries using materialized derived tables or materialized views.
-
- 28 Jun, 2011 1 commit
-
-
Igor Babaev authored
The function create_view_field in some cases incorrectly set the maybe_null flag for the returned items.
-
- 25 Jun, 2011 1 commit
-
-
Igor Babaev authored
Made mergeable views and mergeable derived tables transparent for the MIN/MAX optimization.
-
- 14 Jun, 2011 1 commit
-
-
Igor Babaev authored
Changed the code that processing of multi-updates and multi-deletes with multitable views at the prepare stage. A proper solution would be: never to perform any transformations of views before and at the prepare stage. Yet it would require re-engineering of the code that checks privileges and updatability of views. Ultimately this re-engineering has to be done to provide a clean solution for INSERT/UPDATE/DELETE statements that use views. Fixed a valgrind problem in the function TABLE::use_index.
-
- 09 Jun, 2011 1 commit
-
-
Igor Babaev authored
The function generate_derived_keys did not take into account the fact that the last element in the array of keyuses could be just a barrier element. In some cases it could lead to a crash of the server. Also fixed a couple of other bugs in generate_derived_keys: the inner loop in the body of if this function did not change the cycle variables properly.
-
- 19 May, 2011 1 commit
-
-
Igor Babaev authored
derived_view.test. Do not register Item_ref objects of the type VIEW_REF as outer references.
-
- 26 May, 2010 1 commit
-
-
Igor Babaev authored
The main consolidated patch.
-