An error occurred fetching the project authors.
- 18 Jan, 2012 1 commit
-
-
unknown authored
handler counter Handler_read_rnd_deleted.
-
- 07 Jan, 2012 1 commit
-
-
Sergei Golubchik authored
geometry fields are blobs too.
-
- 24 Dec, 2011 1 commit
-
-
Igor Babaev authored
fixed several defects in the greedy optimization: 1) The greedy optimizer calculated the 'compare-cost' (CPU-cost) for iterating over the partial plan result at each level in the query plan as 'record_count / (double) TIME_FOR_COMPARE' This cost was only used locally for 'best' calculation at each level, and *not* accumulated into the total cost for the query plan. This fix added the 'CPU-cost' of processing 'current_record_count' records at each level to 'current_read_time' *before* it is used as 'accumulated cost' argument to recursive best_extension_by_limited_search() calls. This ensured that the cost of a huge join-fanout early in the QEP was correctly reflected in the cost of the final QEP. To get identical cost for a 'best' optimized query and a straight_join with the same join order, the same change was also applied to optimize_straight_join() and get_partial_join_cost() 2) Furthermore to get equal cost for 'best' optimized query and a straight_join the new code substrcated the same '0.001' in optimize_straight_join() as it had been already done in best_extension_by_limited_search() 3) When best_extension_by_limited_search() aggregated the 'best' plan a plan was 'best' by the check : 'if ((search_depth == 1) || (current_read_time < join->best_read))' The term '(search_depth == 1' incorrectly caused a new best plan to be collected whenever the specified 'search_depth' was reached - even if this partial query plan was more expensive than what we had already found.
-
- 15 Dec, 2011 2 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
set to 'on' by default.
-
- 12 Dec, 2011 1 commit
-
-
Sergei Golubchik authored
* rename all debugging related command-line options and variables to start from "debug-", and made them all OFF by default. * replace "MySQL" with "MariaDB" in error messages * "Cast ... converted ... integer to it's ... complement" is now a note, not a warning * @@query_cache_strip_comments now has a session scope, not global.
-
- 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 .
-
- 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.
-
- 22 Aug, 2011 1 commit
-
-
Sergei Golubchik authored
sql/sql_select.cc: items' cmp_type()'s must match, not result_type()'s
-
- 15 Jul, 2011 1 commit
-
-
Igor Babaev authored
Made it 'off' by default.
-
- 08 Jul, 2011 1 commit
-
-
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
-
- 02 Jul, 2011 1 commit
-
-
Sergei Golubchik authored
most tests pass. 5.3 merge is next
-
- 04 May, 2011 1 commit
-
-
Igor Babaev authored
The bug was introduced by the patch that fixed bug 717577.
-
- 25 Apr, 2011 1 commit
-
-
Sergei Golubchik authored
-
- 02 Apr, 2011 1 commit
-
-
Sergey Petrunya authored
- "Using MRR" is no longer shown with range access. - Instead, both range and BKA accesses will show one of the following: = "Rowid-ordered scan" = "Key-ordered scan" = "Key-ordered Rowid-ordered scan" depending on whether DS-MRR implementation will do scan keys in order, rowids in order, or both. - The patch also introduces a way for other storage engines/MRR implementations to pass information to EXPLAIN output about the properties of employed MRR scans.
-
- 24 Feb, 2011 1 commit
-
-
Igor Babaev authored
even in the cases when there existed range/index-merge scans that were cheaper than the full table scan. This was a defect/bug of the implementation of mwl #128. Now hash join can work not only with full table scan of the joined table, but also with full index scan, range and index-merge scans. Accordingly, in the cases when hash join is used the column 'type' in the EXPLAINs can contain now 'hash_ALL', 'hash_index', 'hash_range' and 'hash_index_merge'. If hash join is coupled with a range/index_merge scan then the columns 'key' and 'key_len' contain info not only on the used hash index, but also on the indexes used for the scan.
-
- 26 Jan, 2011 1 commit
-
-
Igor Babaev authored
The bug was in the code of the patch fixing bug 698882. With improper casting the method store_key_field::change_source_field was called for the elements of the array TABLE_REF::key_copy that were either of a different type or not allocated at all. This caused crashes in some queries.
-
- 16 Jan, 2011 1 commit
-
-
Igor Babaev authored
-
- 15 Jan, 2011 2 commits
-
-
Igor Babaev authored
Made sure that the optimal fields are used by TABLE_REF objects when building index access keys to joined tables. Fixed a bug in the template function that sorts the elements of a list using the bubble sort algorithm. The bug caused poor performance of the function. Also added an optimization that skips comparison with the most heavy elements that has been already properly placed in the list. Made the comparison of the fields belonging to the same Item_equal more granular: fields belonging to the same table are also ordered according to some rules.
-
Igor Babaev authored
An assertion failure was triggered for a 6-way join query that used two join buffers. The failure happened because every call of JOIN_CACHE::join_matching_records saved and restored status of all tables that were accessed before the table join_tab. It must do it only for those of them that follow the last table using a join buffer.
-
- 05 Jan, 2011 1 commit
-
-
Igor Babaev authored
for hash join in the cases when there are no suitable indexes for these conditions.
-
- 18 Oct, 2010 1 commit
-
-
Igor Babaev authored
about the employed join algorithms. Refactored constructors of the JOIN_CACHE* classes.
-
- 13 Oct, 2010 1 commit
-
-
Sergey Petrunya authored
- post-merge fixes
-
- 28 Sep, 2010 1 commit
-
-
Igor Babaev authored
Applied the fix for bug #47217 from the mysql-6.0 codebase. The patch adds not null predicates generated for the left parts of the equality predicates used for ref accesses. This is done for such predicates both in where conditions and on conditions. For the where conditions the not null predicates were generated but in 5.0/5.1 they actually never were used due to some lame merge from 4.1 to 5.0. The fix for bug #47217 made these predicates to be used in the condition pushed to the tables. Yet only this patch generates not null predicates for equality predicated from on conditions of outer joins. This patch introduces a performance regression that can be observed on a test case from null_key.test. The regression will disappear after the fix for bug #57024 from mariadb-5.1 is pulled into mariadb-5.3. The patch contains many changes in the outputs of the EXPLAIN commands since generated not null predicates are considered as parts of the conditions pushed to join tables and may add 'Usingwhere' in some rows of EXPLAINs where there used to be no such comments.
-
- 15 Sep, 2010 1 commit
-
-
Sergey Petrunya authored
- First part of the fix: enable Early NULLs filtering to work when WHERE clause is present
-
- 31 Aug, 2010 1 commit
-
-
Igor Babaev authored
-
- 21 Dec, 2009 1 commit
-
-
Igor Babaev authored
WL#2771 "Block Nested Loop Join and Batched Key Access Join"
-
- 15 Dec, 2009 3 commits
-
-
Ramil Kalimullin authored
NULLable BIGINT and INT columns in comparison Problem: a consequence of the fix for 43668. Some Arg_comparator inner initialization missed, that may lead to unpredictable (wrong) comparison results. Fix: always properly initialize Arg_comparator before its usage. mysql-test/r/select.result: Fix for bug#49517: Inconsistent behavior while using NULLable BIGINT and INT columns in comparison -test result. mysql-test/t/select.test: Fix for bug#49517: Inconsistent behavior while using NULLable BIGINT and INT columns in comparison -test case. sql/item_cmpfunc.cc: Fix for bug#49517: Inconsistent behavior while using NULLable BIGINT and INT columns in comparison - now all Arg_comparator::set_cmp_func() set Arg_comparator::set_null to ensure its proper initialization in all cases (by default it's set to TRUE in constructors). sql/item_cmpfunc.h: Fix for bug#49517: Inconsistent behavior while using NULLable BIGINT and INT columns in comparison - now all Arg_comparator::set_cmp_func() set Arg_comparator::set_null to ensure its proper initialization in all cases (by default it's set to TRUE in constructors).
-
Georgi Kodinov authored
Merge the fix from 5.1-bugteam to 5.1-main
-
Sergey Petrunya authored
WL#2474 "Multi Range Read: Change the default MRR implementation to implement new MRR interface" WL#2475 "Batched range read functions for MyISAM/InnoDb" "Index condition pushdown for MyISAM/InnoDB" Igor's fix from sp1r-igor@olga.mysql.com-20080330055902-07614: There could be observed the following problems: 1. EXPLAIN did not mention pushdown conditions from on expressions in the 'extra' column. As a result if a query had no where conditions pushed down to a table, but had on conditions pushed to this table the 'extra' column in the EXPLAIN for the table missed 'using where'. 2. Conditions for ref access were not eliminated from on expressions though such conditions were eliminated from the where condition.
-
- 11 Dec, 2009 1 commit
-
-
Alexey Kopytov authored
mysql-trunk-merge to take into account the changes introduced by the fix for bug #30302.
-
- 09 Dec, 2009 1 commit
-
-
Evgeny Potemkin authored
Arg_comparator uses Item_cache objects to store constants being compared when they're need a type conversion. Because this cache wasn't initialized properly Arg_comparator might produce wrong comparison result. The Arg_comparator::cache_converted_constant function now initializes cache prior to usage. mysql-test/r/select.result: Added a test case for he bug#49489. mysql-test/t/select.test: Added a test case for he bug#49489. sql/item_cmpfunc.cc: Bug#49489: Uninitialized cache led to a wrong result. The Arg_comparator::cache_converted_constant function now initializes cache prior to usage.
-
- 04 Dec, 2009 1 commit
-
-
Ramil Kalimullin authored
field='const1' AND field='const2' in some cases Building multiple equality predicates containing a constant which is compared as a datetime (with a field) we should take this fact into account and compare the constant with another possible constatns as datetimes as well. E.g. for the SELECT ... WHERE a='2001-01-01' AND a='2001-01-01 00:00:00' we should compare '2001-01-01' with '2001-01-01 00:00:00' as datetimes but not as strings. mysql-test/r/select.result: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - test result. mysql-test/t/select.test: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - test case. sql/item_cmpfunc.cc: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - adding a constant to Item_equal compare it as a datetime value with stored one if there's a date[time] field in a equality predicate. sql/item_cmpfunc.h: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - adding a constant to Item_equal compare it as a datetime value with stored one if there's a date[time] field in a equality predicate. sql/sql_select.cc: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - adding a constant to Item_equal compare it as a datetime value with stored one if there's a date[time] field in a equality predicate.
-
- 01 Dec, 2009 1 commit
-
-
Evgeny Potemkin authored
Constant expressions in WHERE/HAVING/ON clauses aren't cached and evaluated for each row. This causes slowdown of query execution especially if constant UDF/SP function are used. Now WHERE/HAVING/ON expressions are analyzed in the top-bottom direction with help of the compile function. When analyzer meets a constant item it sets a flag for the tree transformer to cache the item and doesn't allow tree walker to go deeper. Thus, the topmost item of a constant expression if cached. This is done after all other optimizations were applied to WHERE/HAVING/ON expressions A helper function called cache_const_exprs is added to the JOIN class. It calls compile method with caching analyzer and transformer on WHERE, HAVING, ON expressions if they're present. The cache_const_expr_analyzer and cache_const_expr_transformer functions are added to the Item class. The first one check if the item can be cached and the second caches it if so. A new Item_cache_datetime class is derived from the Item_cache class. It caches both int and string values of the underlying item independently to avoid DATETIME aware int-to-string conversion. Thus it completely relies on the ability of the underlying item to correctly convert DATETIME value from int to string and vice versa. mysql-test/r/func_like.result: A test case result is corrected after fixing bug#33546. mysql-test/r/func_time.result: A test case result is corrected after fixing bug#33546. mysql-test/r/select.result: Added a test case for the bug#33546. mysql-test/r/subselect.result: A test case result is corrected after fixing bug#33546. mysql-test/r/udf.result: Added a test case for the bug#33546. mysql-test/t/select.test: Added a test case for the bug#33546. mysql-test/t/udf.test: Added a test case for the bug#33546. sql/item.cc: Bug#33546: Slowdown on re-evaluation of constant expressions. The cache_const_expr_analyzer and cache_const_expr_transformer functions are added to the Item class. The first one check if the item can be cached and the second caches it if so. Item_cache_datetime class implementation is added. sql/item.h: Bug#33546: Slowdown on re-evaluation of constant expressions. Item_ref and Item_cache classes now returns basic_const_item from underlying item. The cache_const_expr_analyzer and cache_const_expr_transformer functions are added to the Item class. sql/sql_select.cc: Bug#33546: Slowdown on re-evaluation of constant expressions. A helper function called cache_const_exprs is added to the JOIN class. It calls compile method with caching analyzer and transformer on WHERE, HAVING, ON expressions if they're present. sql/sql_select.h: Bug#33546: Slowdown on re-evaluation of constant expressions. A helper function called cache_const_exprs is added to the JOIN class.
-
- 25 Nov, 2009 2 commits
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 1810.3961.7 > committer: Georgi Kodinov <joro@sun.com> > branch nick: B48291-5.0-bugteam > timestamp: Fri 2009-10-30 15:15:43 +0200 > message: > Bug #48291 : crash with row() operator,select into @var, and > subquery returning multiple rows > > Error handling was missing when handling subqueires in WHERE > and when assigning a SELECT result to a @variable. > This caused crash(es). > > Fixed by adding error handling code to both the WHERE > condition evaluation and to assignment to an @variable. > ------------------------------------------------------------
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 1810.3959.4 > revision-id: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c > parent: azundris@mysql.com-20091021033856-ydodp4q42o58e7ka > committer: Ramil Kalimullin <ramil@mysql.com> > branch nick: b47019-5.0-bugteam > timestamp: Wed 2009-10-21 14:04:08 +0500 > message: > Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, > line 138 when forcing a spatial index > > Problem: "Spatial indexes can be involved in the search > for queries that use a function such as MBRContains() > or MBRWithin() in the WHERE clause". > Using spatial indexes for JOINs with =, <=> etc. > predicates is incorrect. > > Fix: disable spatial indexes for such queries.
-
- 13 Nov, 2009 1 commit
-
-
Jorgen Loland authored
init_read_record() - (records.cc:274) Item_cond::used_tables_cache was accessed in records.cc#init_read_record() without being initialized. It had not been initialized because it was wrongly assumed that the Item's variables would not be accessed, and hence quick_fix_field() was used instead of fix_fields() to save a few CPU cycles at creation time. The fix is to properly initilize the Item by replacing quick_fix_field() with fix_fields(). mysql-test/r/select.result: Add test for BUG#48052 mysql-test/t/select.test: Add test for BUG#48052 sql/sql_select.cc: Properly initialize Item_cond_and by calling fix_fields (instead of quick_fix_field) when the Item that "ANDs" WHERE clause conditions with HAVING clause conditions is created.
-
- 09 Nov, 2009 1 commit
-
-
Georgi Kodinov authored
memory The server was doing a bad class typecast causing setting of wrong value for the maximum number of items in an internal structure used in equality propagation. Fixed by not doing the wrong typecast and asserting the type of the Item where it should be done.
-
- 30 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
subquery returning multiple rows Error handling was missing when handling subqueires in WHERE and when assigning a SELECT result to a @variable. This caused crash(es). Fixed by adding error handling code to both the WHERE condition evaluation and to assignment to an @variable.
-
- 21 Oct, 2009 1 commit
-
-
Ramil Kalimullin authored
line 138 when forcing a spatial index Problem: "Spatial indexes can be involved in the search for queries that use a function such as MBRContains() or MBRWithin() in the WHERE clause". Using spatial indexes for JOINs with =, <=> etc. predicates is incorrect. Fix: disable spatial indexes for such queries. mysql-test/r/select.result: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - test result. mysql-test/t/select.test: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - test case. sql/sql_select.cc: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - disable spatial indexes for queries which use non-spatial conditions (e.g. NATURAL JOINs).
-