An error occurred fetching the project authors.
- 09 Sep, 2013 1 commit
-
-
Sergei Golubchik authored
-
- 26 Aug, 2013 1 commit
-
-
Sergei Golubchik authored
don't log it to the error log.
-
- 28 Aug, 2013 1 commit
-
-
Igor Babaev authored
The fix for mdev-4420 was not quite correct. This patch corrects it.
-
- 26 Aug, 2013 2 commits
-
-
Igor Babaev authored
When in function remove_eq_conds() a sub-formula of the processed condition is replaced for another formula we should ensure that in the resulting formula AND/OR levels must alternate.
-
Igor Babaev authored
The patch to fix mdev-4418 turned out to be incorrect. At the substitution of single row tables in make_join_statistics() the used multiple equalities may change and references to the new multiple equalities must be updated. The function remove_eq_conds() takes care of it and it should be called right after the substitution of single row tables. Calling it after the call of make_join_statistics was a mistake.
-
- 24 Aug, 2013 1 commit
-
-
Igor Babaev authored
Made sure that degenerate conjunctions/disjunctions are obtained from AND/OR conditions.
-
- 23 Aug, 2013 1 commit
-
-
Igor Babaev authored
The code of JOIN::optimize that performed substitutions for the best equal field in all ref items did not take into account that a multiple equality could contain the result of the single-value subquery if the subquery is inexpensive. This code was corrected. Also made necessary corresponding corrections in the code of make_join_select().
-
- 20 Aug, 2013 1 commit
-
-
Igor Babaev authored
had been merged into 5.5. Corrected the result of the output from the test case for mdev 4895.
-
- 19 Aug, 2013 1 commit
-
-
Igor Babaev authored
had been discovered when merging the patch from 5.3 into 5.5.
-
- 17 Aug, 2013 1 commit
-
-
Igor Babaev authored
After single row substitutions there might appear new equalities. They should be properly propagated to all AND/OR levels the WHERE condition. It's done now with an additional call of remove_eq_conds().
-
- 15 Aug, 2013 1 commit
-
-
Igor Babaev authored
This patch almost totally revised the patch for bug mdev-4177. The latter had too many defects. In particular, it did not propagate multiple equalities formed when merging a degenerate disjunct into underlying AND formula.
-
- 13 Aug, 2013 1 commit
-
-
Igor Babaev authored
This a an old legacy performance bug. When a very selective range scan existed for the second table in a join, and, at the same time, there was another range condition depending on the fields of the first table, the optimizer chose a plan with 'Range checked for each record'. This plan was extremely inefficient in comparison with the regular selective range scan. As a matter of fact the range scan chosen for each record was the same as that selective range scan. Changed the test case for bug 24776 to preserve the old output for explain.
-
- 18 Jul, 2013 1 commit
-
-
unknown authored
-
- 17 Jul, 2013 1 commit
-
-
unknown authored
In the case of loose scan used as input for order by, end_send() didn't detect correctly that a loose scan was used, and didn't copy the non-aggregated fields from the temp table used for ORDER BY. The fix uses the fact that the quick select used for sorting is attached to JOIN::pre_sort_join_tab instead of JOIN::join_tab.
-
- 16 Jul, 2013 2 commits
-
-
Sergey Petrunya authored
MDEV-4782: Valgrind warnings (Conditional jump or move depends on uninitialised value) with InnoDB, semijoin - in sub_select(): don't call table->file->position() when reading the first record produced an error.
-
Sergey Petrunya authored
mdev-4173: Wrong result (extra row) with semijoin=on, joins in outer query, LEFT JOIN in the subquery Apply the patch from Patryk Pomykalski: - create_internal_tmp_table_from_heap() will now return information whether the last row that we tried to write was a duplicate row. (mysql-5.6 also has this change)
-
- 15 Jul, 2013 1 commit
-
-
Sergey Petrunya authored
- Make JOIN::cleanup(true) also work correctly when the query is KILLed after join optimization was started but before a query plan was produced
-
- 11 Jul, 2013 1 commit
-
-
Sergey Petrunya authored
MDEV-4536: ...sql/sql_base.cc:1598: bool close_thread_table(THD*, TABLE**): Assertion - Make JOIN::cleanup(full=true) always free join optimization tabs.
-
- 05 Jul, 2013 1 commit
-
-
Sergei Golubchik authored
MDEV-4643 MariaDB crashes consistently when trying a SELECT on VIEW with a UNION and an additional JOIN in SELECT open derived temp tables *before* trying QUICK_SELECT for them, handler::multi_range_read_info() needs an open table.
-
- 05 Jun, 2013 1 commit
-
-
Michael Widenius authored
-Run test suite with smaller aria keybuffer size (to make it possible to run more tests in parallel) -Added test and extra code to ensure we don't leave keyread on for a handler table. -Create on disk temporary files always with long data pointers if SQL_SMALL_RESULT is not used. This ensures that we can handle temporary files bigger than 4G. mysql-test/include/default_mysqld.cnf: Run test suite with smaller aria keybuffer size mysql-test/suite/maria/maria3.result: Run test suite with smaller aria keybuffer size mysql-test/suite/sys_vars/r/aria_pagecache_buffer_size_basic.result: Run test suite with smaller aria keybuffer size sql/handler.cc: Disable key read (extra safety if something went wrong) sql/multi_range_read.cc: Ensure we have don't leave keyread on for secondary_file sql/opt_range.cc: Simplify code with mark_columns_used_by_index_no_reset() Ensure that read_keys_and_merge() disableds keyread if it enables it sql/opt_subselect.cc: Remove not anymore used argument for create_internal_tmp_table() sql/sql_derived.cc: Remove not anymore used argument for create_internal_tmp_table() sql/sql_select.cc: Use 'enable_keyread()' instead of calling HA_EXTRA_RESET. (Makes debugging easier) Create on disk temporary files always with long data pointers if SQL_SMALL_RESULT is not used. This ensures that we can handle temporary files bigger than 4G. Remove not anymore used argument for create_internal_tmp_table() More DBUG sql/sql_select.h: Remove not anymore used argument for create_internal_tmp_table()
-
- 11 May, 2013 1 commit
-
-
Michael Widenius authored
MDEV-4280: Assertion `empty_size == empty_size_on_page' failure in ma_blockrec.c or ER_NOT_KEYFILE on query with DISTINCT and GROUP BY This could happen when using Aria for internal temporary files (default case) and using DISTINCT. _ma_scan_restore_block_record() didn't work correctly if there was rows inserted, updated or deleted on the handler between calls to _ma_scan_remember_block_record() and _ma_scan_restore_block_record(). The effect was that some DISTINCT queries that used remove_dup_with_compare() could fail. .bzrignore: Ignore sql_yacc.hh mysql-test/suite/maria/r/distinct.result: Test case for MDEV-4280 mysql-test/suite/maria/t/distinct.test: Test case for MDEV-4280 mysql-test/t/mysql.test: Fixed test suite (we could get error -1 in some cases) sql/sql_select.cc: Break loop if restart_rnd_next() gives an error storage/maria/ha_maria.cc: scan_restore_pos() can return disk fault error. storage/maria/ma_blockrec.c: _ma_scan_remember_block_record() did incorrectly update scan.dir instead of scan_save.dir . _ma_scan_restore_block_record() didn't work correctly if there was rows inserted,updated or deleted on the handler between calls to _ma_scan_remember_block_record() and _ma_scan_restore_block_record(). Fixed by adding counters for row changes and reading the current scan page if changes had been made. storage/maria/ma_blockrec.h: scan_restore_pos() can return disk fault error. storage/maria/ma_delete.c: Increment row_changes storage/maria/ma_scan.c: scan_restore_pos() can return disk fault error. storage/maria/ma_update.c: Increment row_changes storage/maria/ma_write.c: Increment row_changes storage/maria/maria_def.h: scan_restore_pos() can return disk fault error.
-
- 04 May, 2013 3 commits
-
-
Sergey Petrunya authored
- Call tmp_having->update_used_tables() *before* we have call JOIN::cleanup(). Making the call after join::cleanup() is not allowed, because subquery predicate items walk parent join's JOIN_TAB structures. Which can be invalidated by JOIN::cleanup().
-
Igor Babaev authored
When iterating over a list of conditions using List_iterator the function remove_eq_conds should skip all predicates that replace a condition from the list. Otherwise it can come to an infinite recursion.
-
Igor Babaev authored
<non-nullable datatime field> IS NULL in outer joins with that in inner joins. Previously such condition was transformed into the condition <non-nullable datatime field> = 0 unless the field belonged to an inner table of an outer join. In this case the predicate was interpreted as for any other field. Now if the field in the predicate <non-nullable datatime field> IS NULL belongs to an inner table of an outer join the predicate is transformed into the disjunction <non-nullable datatime field> = 0 OR <non-nullable datatime field> IS NULL. This is fully compatible with the semantics of such predicates in 5.5.
-
- 03 May, 2013 1 commit
-
-
Sergey Petrunya authored
- When restore_prev_nj_state() is called for the table that is the last remaining child of a nested join, do not leave that nested join's bit in join->cur_embedding_map.
-
- 30 Apr, 2013 1 commit
-
-
Igor Babaev authored
This bug was the result of incompleteness of the patch for bug mdev-4177. When an OR condition is simplified to a single conjunct it is merged into the embedding AND condition. Multiple equalities are also merged, and any field item involved in those equality should acquire a pointer to a the multiple equality formed by this merge.
-
- 28 Apr, 2013 1 commit
-
-
Igor Babaev authored
The function make_join_statistics checks whether eq_ref access uses only constant expressions, and, if this is the case the function performs constant row substitution. The code of this check must take into account hidden components of extended secondary keys.
-
- 06 Apr, 2013 1 commit
-
-
Sergei Golubchik authored
fulltext search was initialized for all MATCH ... AGAINST items at the end of the JOIN::optimize(). But since 5.3 derived tables are initialized lazily on first use, very late in the sub_select(). Skip Item_func_match::init_search initialization if the corresponding table isn't open yet; repeat fulltext initialization for all not-yet-initialized MATCH ... AGAINST items after creating derived tables.
-
- 04 Apr, 2013 1 commit
-
-
Sergei Golubchik authored
init join->top_join_tab_count to be in sync with join->join_tab=stat, otherwise a query can be killed in-between and join_tab's won't be deleted (JOIN::cleanup won't call JOIN_TAB::cleanup)
-
- 02 Apr, 2013 1 commit
-
-
Tor Didriksen authored
This is a backport of the fix for Bug#13966809 CRASH IN COPY_FUNCS WHEN GROUPING BY OUTER QUERY BLOB FIELD IN SUBQUERY
-
- 23 Mar, 2013 1 commit
-
-
Igor Babaev authored
In some cases, when using views the optimizer incorrectly determined possible join orders for queries with nested outer and inner joins. This could lead to invalid execution plans for such queries.
-
- 20 Mar, 2013 1 commit
-
-
Jorgen Loland authored
RETURNS RANDOM DATA MySQL 5.5 specific version of bugfix. When Loose Index Scan Range access is used, MySQL execution needs to copy non-aggregated fields. end_send() checked if this was necessary by checking if join_tab->select->quick had type QS_TYPE_GROUP_MIN_MAX. In this bug, however, MySQL created a sort index to sort the rows read from this range access method. create_sort_index() deletes join_tab->select->quick which makes it impossible to inquire the join_tab if LIS has been used. The fix for MySQL 5.5 is to introduce a variable in JOIN_TAB that stores whether or not LIS has been used. There is no need for this variable in later MySQL versions because the relevant code has been refactored.
-
- 19 Mar, 2013 2 commits
-
-
Murthy Narkedimilli authored
-
Murthy Narkedimilli authored
-
- 18 Mar, 2013 1 commit
-
-
unknown authored
Item_default_value inherited form Item_field so should create temporary table field similary.
-
- 08 Mar, 2013 1 commit
-
-
Igor Babaev authored
This is a bug in the legacy code. It did not manifest itself because it was masked by other bugs that were fixed by the patches for mdev-4172 and mdev-4177.
-
- 02 Mar, 2013 1 commit
-
-
Igor Babaev authored
This bug is a regression bug. The regression was introduced by the patch for mdev-3851, that tried to weaken the condition when a ref access with an extended key can be converted to an eq_ref access. The patch incorrectly formed this condition. As a result, while improving performance for some queries, the patch caused worse performance for another queries.
-
- 28 Feb, 2013 1 commit
-
-
Igor Babaev authored
Do not include BLOB fields into the key to access the temporary table created for a materialized view/derived table. BLOB components are not allowed in keys.
-
- 25 Feb, 2013 1 commit
-
-
Igor Babaev authored
The function remove_eq_cond removes the parts of a disjunction for which it has been proved that they are always true. In the result of this removal the disjunction may be converted into a formula without OR that must be merged into the the AND formula that contains the disjunction. The merging of two AND conditions must take into account the multiple equalities that may be part of each of them. These multiple equality must be merged and become part of the and object built as the result of the merge of the AND conditions. Erroneously the function remove_eq_cond lacked the code that would merge multiple equalities of the merged AND conditions. This could lead to confusing situations when at the same AND level there were two multiple equalities with common members and the list of equal items contained only some of these multiple equalities. This, in its turn, could lead to an incorrect work of the function substitute_for_best_equal_field when it tried to optimize ref accesses. This resulted in forming invalid TABLE_REF objects that were used to build look-up keys when materialized subqueries were exploited.
-
- 22 Feb, 2013 1 commit
-
-
Igor Babaev authored
This bug in the legacy code could manifest itself in queries with semi-join materialized subqueries. When a subquery is materialized all conditions that are imposed only on the columns belonging to the tables from the subquery are taken into account.The code responsible for subquery optimizations that employes subquery materialization makes sure to remove these conditions from the WHERE conditions of the query obtained after it has transformed the original query into a query with a semi-join. If the condition to be removed is an equality condition it could be added to ON expressions and/or conditions from disjunctive branches (parts of OR conditions) in an attempt to generate better access keys to the tables of the query. Such equalities are supposed to be removed later from all the formulas where they have been added to. However, erroneously, this was not done in some cases when an ON expression and/or a disjunctive part of the OR condition could be converted into one multiple equality. As a result some equality predicates over columns belonging to the tables of the materialized subquery remained in the ON condition and/or the a disjunctive part of the OR condition, and the excuter later, when trying to evaluate them, returned wrong answers as the values of the fields from these equalities were not valid. This happened because any standalone multiple equality (a multiple equality that are not ANDed with any other predicates) lacked the information about equality predicates inherited from upper levels (in particular, inherited from the WHERE condition). The fix adds a reference to such information to any standalone multiple equality.
-