An error occurred fetching the project authors.
- 25 Nov, 2011 1 commit
-
-
Sergey Petrunya authored
- Make EXPLAIN display "Start temporary" at the start of the fanout (it used to display at the first table whose rowid gets into temp. table which is not that useful for the user) - Updated test results (all checked)
-
- 23 Nov, 2011 1 commit
-
-
Sergey Petrunya authored
- Break down POSITION/advance_sj_state() into four classes representing potential semi-join strategies. - Treat all strategies uniformly (before, DuplicateWeedout was special as it was the catch-all strategy. Now, we're still relying on it to be the catch-all, but are able to function,e.g. with firstmatch=on,duplicate_weedout=off. - Update test results (checked)
-
- 11 Nov, 2011 1 commit
-
-
Igor Babaev authored
The function add_ref_to_table_cond missed updating the value of join_tab->pre_idx_push_select_cond after having updated the value of join_tab->select->pre_idx_push_select_cond.
-
- 07 Nov, 2011 1 commit
-
-
Sergey Petrunya authored
- Do not push index condition if we're using a triggered ref access.
-
- 06 Nov, 2011 1 commit
-
-
Igor Babaev authored
The bug happened because in some cases the function JOIN::exec did not save the value of TABLE::pre_idx_push_select_cond in TABLE::select->pre_idx_push_select_cond for the sort table. Noticed and fixed a bug in the function make_cond_remainder that builds the remainder condition after extraction of an index pushdown condition from the where condition. The code erroneously assumed that the function make_cond_for_table left the value of ICP_COND_USES_INDEX_ONLY in sub-condition markers. Adjusted many result files from the regression test suite after this fix .
-
- 04 Nov, 2011 1 commit
-
-
Igor Babaev authored
The call of the virtual function cancel_pushed_idx_cond in the code of the function test_if_skip_sort_order was misplaced when backporting the fix for bug 58816.
-
- 01 Nov, 2011 1 commit
-
-
Igor Babaev authored
Fixed a bug in select_describe. Adjusted results for affected test cases.
-
- 31 Oct, 2011 1 commit
-
-
Sergey Petrunya authored
- The bug was caused by the following scenario: = a quick select is created with get_quick_select_for_ref. The quick select refers to temporary (derived) table. It saves table->file, which refers to a ha_heap object. = When temp table is populated, ha_heap reaches max. size and is converted to a ha_myisam. However, quick->file remains pointing to where ha_heap was. = Attempt to use the quick select causes crash. - Fixed by introducing QUICK_SELECT_I::replace_handler(). Note that it will not work for index_merge quick selects. Which is fine, because these quick selects are never created for derived tables.
-
- 29 Oct, 2011 1 commit
-
-
Igor Babaev authored
-
- 27 Oct, 2011 1 commit
-
-
Sergey Petrunya authored
- The problem was that the value of READ_RECORD::file was not updated when the underlying table was temporary and was converted from heap to myisam. Resolved by eliminating READ_RECORD::file, always use READ_RECORD::table->file
-
- 26 Oct, 2011 1 commit
-
-
Michael Widenius authored
Honor unique/not unique when creating keys for internal tempory tables. Added new variables to be used to limit how keys are created for internal temporary tables. include/maria.h: Added maria_max_key_length() and maria_max_key_segments() include/myisam.h: Added myisam_max_key_length() and myisam_max_key_segments() mysql-test/r/mysql.result: Drop all used tables mysql-test/r/subselect4.result: Added test case for lp:879939 mysql-test/t/mysql.test: Drop all used tables mysql-test/t/subselect4.test: Added test case for lp:879939 sql/mysql_priv.h: Added internal_tmp_table_max_key_length and internal_tmp_table_max_key_segments to be used to limit how keys for derived tables are created. sql/mysqld.cc: Added internal_tmp_table_max_key_length and internal_tmp_table_max_key_segments to be used to limit how keys for derived tables are created. sql/share/errmsg.txt: Added new error message for internal errors sql/sql_select.cc: Give error if we try to create a wrong key (this error should never happen) Honor unique/not unique when creating keys for internal tempory tables. storage/maria/ha_maria.cc: Added change_table_ptr() to ensure that external_ref points always to the correct table. (Not having this caused an assert in the included test) storage/maria/ha_maria.h: Added change_table_ptr() to ensure that external_ref points always to the correct table. storage/maria/ma_check.c: Fixed bug in Duplicate key error printing (now row position is printed correctly) storage/maria/ma_create.c: maria_max_key_length() -> _ma_max_key_length() storage/maria/ma_info.c: Added extern function maria_max_key_length() to calculate the max key length based on current block size. storage/maria/ma_open.c: maria_max_key_length() -> _ma_max_key_length() storage/maria/maria_def.h: maria_max_key_length() -> _ma_max_key_length() storage/myisam/ha_myisam.cc: Added change_table_ptr() to ensure that external_ref points always to the correct table. (Not having this caused an assert in the included test) storage/myisam/ha_myisam.h: Added change_table_ptr() to ensure that external_ref points always to the correct table.
-
- 25 Oct, 2011 1 commit
-
-
Sergey Petrunya authored
- when create_ref_for_key() is constructing a ref access for a table that's inside a SJ-Materialization nest, it may not use references to fields of tables that are unside the nest (because these fields will not yet have values when ref access will be used) The check was performed in the first of create_ref_for_key's loops (the one which counts how many key parts are usable) but not in the second (the one which actually fills the TABLE_REF structure).
-
- 24 Oct, 2011 1 commit
-
-
Igor Babaev authored
Do not create KEYUSEs for a materialized view over a constant table.
-
- 20 Oct, 2011 1 commit
-
-
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.
-
- 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.
-
- 12 Oct, 2011 3 commits
-
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
- 11 Oct, 2011 2 commits
-
-
Sergey Petrunya authored
- in make_join_select(), use the correct condition to check whether the current table is a SJM nest (the previous condition used to be correct before, but then sj-materialization temp table creation was moved to happen before make_join_select was called)
-
Igor Babaev authored
This bug is a consequence of the fix in the function add_ref_to_table_cond for LP bug 826935 that turned out to be not quite correct: it tried to AND the same generated condition with two different other conditions. This patch creates a copy of the generated condition if the condition needs to be ANDed with two different items.
-
- 04 Oct, 2011 1 commit
-
-
Igor Babaev authored
Changed a test case to make its result set platform independent.
-
- 01 Oct, 2011 2 commits
-
-
Igor Babaev authored
in the function best_access_path revealed another bug: currently table scans on NULL keys used for NOT IN subqueries cannot work together with employment of join caches for inner tables of these subqueries. Otherwise the result can be wrong as it could be seen with the result of the test case constructed for bug #37894 in the file subselect3_jcl6.result.
-
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.
-
- 30 Sep, 2011 1 commit
-
-
Sergey Petrunya authored
- The problem was that JOIN::save/restore_query_plan() did not save/restore parts of the query plan that are located inside SJ_MATERIALIZATION_INFO structures. This could cause parts of one plan to be used with another, which led get_best_combination() to constructing non-sensical join plans (and crash). Fixed by saving/restoring SJM parts of the query plans. - check_and_do_in_subquery_rewrites() will not set SUBS_MATERIALIZATION flag when it records that the subquery predicate is to be converted into semi-join. If convert_join_subqueries_to_semijoins() later decides not to convert to semi-join, let it set SUBS_MATERIALIZATION flag, if appropriate.
-
- 29 Sep, 2011 1 commit
-
-
Sergey Petrunya authored
- are_tables_local() failed to recognize the fact that OUTER_REF_TABLE_BIT is ok for SJ-Materialization. This caused zero-length ref access to be constructed, which led to an assert.
-
- 08 Sep, 2011 1 commit
-
-
Sergey Petrunya authored
- Let join buffering code correctly take into account rowids needed by DuplicateElimination when it is calculating minimum record sizes. - In JOIN_CACHE::write_record_data, added asserts that prevent us from writing beyond the end of the buffer.
-
- 06 Sep, 2011 1 commit
-
-
Igor Babaev authored
For any query JOIN::optimize() should call the method SELECT::save_leaf_tables after the last transformation that utilizes the statement memory rather than the execution memory.
-
- 05 Sep, 2011 1 commit
-
-
Sergey Petrunya authored
- Don't use join buffering for tables that are within ranges that are covered by LooseScan strategy.
-
- 03 Sep, 2011 1 commit
-
-
Michael Widenius authored
Fixed lp:828514 "Assertion `! is_set()' failed in Diagnostics_area::set_ok_status with derived table + subquery + concurrent DML" sql/item_subselect.cc: Added check of error condtions (safety) sql/sql_join_cache.cc: Added DBUG to some functions. Added error checking for calls to check_match(); This fixed the bug. sql/sql_select.cc: Moved variable assignment to be close to where it's used (cleanup)
-
- 02 Sep, 2011 1 commit
-
-
Sergey Petrunya authored
- Make JOIN::get_partial_cost_and_fanout() be able to handle join plans with semi-join-materialization nests.
-
- 01 Sep, 2011 1 commit
-
-
unknown authored
Analysis: In the test query semi-join merges the inner-most subquery into the outer subquery, and the optimization of the merged subquery finds some new index access methods. Later the IN-EXISTS transformation is applied to the unmerged subquery. Since the optimizer is instructed to not consider materialization, it reoptimizes the plan in-place to take into account the new IN-EXISTS conditions. Just before reoptimization JOIN::choose_subquery_plan resets the query plan, which also resets the access methods found during the semi-join merge. Then reoptimization discovers there are no new access methods, but it leaves the query plan in its reset state. Later semi-join crashes because it assumes these access methods are present. Solution: When reoptimizing in-place, reset the query plan only after new access methods were discovered. If no new access methods were discovered, leave the current plan as it was.
-
- 29 Aug, 2011 1 commit
-
-
Sergey Petrunya authored
BUG##836491: Crash in Item_field::Item_field from add_ref_to_table_cond() with semijoin+materialization - Let create_tmp_table set KEY_PART_INFO::fieldnr. It is needed in add_ref_to_table_cond(), and possibly other places.
-
- 26 Aug, 2011 1 commit
-
-
unknown authored
Analysis: Constant table optimization of the outer query finds that the right side of the equality is a constant that can be used for an eq_ref access to fetch one row from t1, and substitute t1 with a constant. Thus constant optimization triggers evaluation of the subquery during the optimize phase of the outer query. The innermost subquery requires a plan with a temporary table because with InnoDB tables the exact count of rows is not known, and the empty tables cannot be optimzied way. JOIN::exec for the innermost subquery substitutes the subquery tables with a temporary table. When EXPLAIN gets to print the tables in the innermost subquery, EXPLAIN needs to print the name of each table through the corresponding TABLE_LIST object. However, the temporary table created during execution doesn't have a corresponding TABLE_LIST, so we get a null pointer exception. Solution: The solution is to forbid using expensive constant expressions for eq_ref access for contant table optimization. Notice that eq_ref with a subquery providing the value is still possible during regular execution.
-
- 22 Aug, 2011 1 commit
-
-
Sergei Golubchik authored
sql/sql_select.cc: items' cmp_type()'s must match, not result_type()'s
-
- 20 Aug, 2011 1 commit
-
-
Igor Babaev authored
When the WHERE/HAVING condition of a subquery has been transformed by the optimizer the pointer stored the 'where'/'having' field of the SELECT_LEX structure used for the subquery must be updated accordingly. Otherwise the pointer may refer to an invalid item. This can lead to the reported assertion failure for some queries with correlated subqueries
-
- 17 Aug, 2011 1 commit
-
-
Sergey Petrunya authored
BUG#826935 Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed - add_ref_to_table_cond() should not just overwrite pre_idx_push_select_cond with the contents tab->select_cond. pre_idx_push_select_cond exists precisely for the reason that it may contain a condition that is a strict superset of what is in tab->select_cond. The fix is to inject generated equality into pre_idx_push_select_cond.
-
- 16 Aug, 2011 1 commit
-
-
Sergey Petrunya authored
- Make simplify_joins() set maybe_null=FALSE for tables that were on the inner sides of inner joins and then were moved to the inner sides of semi-joins.
-
- 09 Aug, 2011 1 commit
-
-
unknown authored
This bug is a special case of lp:813447. Analysis: Constant optimization finds that the condition t2.a = 1 can be used to access the primary key of table 't2'. As a result both outer table t1,t2 are considered as constant when we reach the execution phase. At the same time, during constant optimization, the IN predicate is not evaluated because it is expensive. When execution of the outer query reaches do_select(), control flow enter the branch: if (join->table_count == join->const_tables) { ... } This branch checks only the WHERE and HAVING clauses, but doesn't check the ON clauses of the query. Since the IN predicate was not evaluated during optimization, it is not evaluated at all, thus execution doesn't detect that the ON clause is FALSE. Solution: Similar to the patch for bug lp:813447, exclude system tables from constant substitution based on unique key lookups if there is an expensive ON condition on the inner table.
-
- 08 Aug, 2011 1 commit
-
-
Sergey Petrunya authored
- create_ref_for_key() has the code that walks KEYUSE array and tries to use maximum number of keyparts for ref (and eq_ref and ref_or_null) access. When one constructs ref access for table that is inside a SJ-Materialization nest, it is not possible to use tables that are ouside the nest (because materialization is performed before they have any "current value"). The bug was caused by this function not taking this into account.
-
- 30 Jul, 2011 1 commit
-
-
Igor Babaev authored
This problem could be observed for queries with nested outer joins for which the not_exist optimization were applicable. The problem was caused by the code of the patch for bug #49322 that erroneously forced the return to the previous nested loop level when the join algorithm successfully builds a partial record for an embedded outer to which the not_exist optimization could be applied. Actually the immediate return to the previous nested loops level is correct only if this partial record is rejected by a predicate pushed down to one of the inner tables of this outer join. Otherwise attempts to find extensions of this record must be made.
-