An error occurred fetching the project authors.
- 30 Aug, 2013 1 commit
-
-
Igor Babaev authored
The function propagate_new_equalities() did not updated properly the references to inherited multiple equalities.
-
- 26 Aug, 2013 1 commit
-
-
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.
-
- 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.
-
- 08 May, 2013 1 commit
-
-
Alexander Barkov authored
MDEV-4489 "Replication of big5, cp932, gbk, sjis strings makes wrong values on slave" has been fixed. Problem: String constants of some Asian charsets (big5,cp932,gbk,sjis) can have backslash '\' (0x5C) in the second byte of multi-byte characters. Replicating of such constants using the standard '\'-escaping is dangerous. Therefore, constants of these charsets are replicated using hex notation: INSERT INTO t1 (a) VALUES (0x815C); However, 0xHHHH constants do not work well in some cases, because they can behave as strings and as numbers, depending on context (for example, depending on the data type of the column in an INSERT statement). This SQL script was not replicated correctly with statement-based replication: SET NAMES gbk; PREPARE STMT FROM 'INSERT INTO t1 (a) VALUES (?)'; SET @A = '1'; EXECUTE STMT USING @A; The INSERT statement was replicated as: INSERT INTO t1 (a) VALUES (0x31); '1' was correctly converted to the number 1 on master. But the 0x31 constant was treated as number 49 on slave. Fix: 1. Binary log now uses X'HHHH' instead of 0xHHHH constants. 2. The X'HHHH' constants now work always as strings, in all contexts. This is the SQL standard compliant behaviour. After the fix, the above statement is replicated as: INSERT INTO t1 (a) VALUES (X'31'); X'31' is treated as string '1' on slave, and is correctly converted to 1. modified: @ mysql-test/r/ctype_cp932_binlog_stm.result @ mysql-test/r/select.result @ mysql-test/r/select_jcl6.result @ mysql-test/r/select_pkeycache.result @ mysql-test/r/user_var-binlog.result @ mysql-test/r/varbinary.result @ mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result @ mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result @ mysql-test/suite/rpl/r/rpl_charset_sjis.result @ mysql-test/suite/rpl/r/rpl_mdev382.result @ mysql-test/suite/rpl/t/rpl_charset_sjis.test @ mysql-test/t/ctype_cp932_binlog_stm.test @ mysql-test/t/select.test @ mysql-test/t/varbinary.test Adding and updating tests @ sql/item.cc @ sql/item.h @ sql/sql_yacc.yy @ sql/sql_lex.cc Splitting the implementations of X'HH' and 0xHH constants into two separate classes. Fixing the parser to distinguish the two syntaxes. @ sql/log_event.cc Using X'HH' instead of 0xHH for binary logging for string constants of the "dangerous" charsets. @ sql/sql_string.h Adding a helped method String::append_hex().
-
- 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.
-
- 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.
-
- 30 Sep, 2012 1 commit
-
-
Igor Babaev authored
In some rare cases when the value of the system variable join_buffer_size was set to a number less than 256 the function JOIN_CACHE::set_constants determined the size of an offset in the join buffer equal to 1 though the minimal join buffer required more than 256 bytes. This could cause a crash of the server when records from the join buffer were read.
-
- 07 May, 2012 1 commit
-
-
unknown authored
In 5.3 we substitute constants in ref access values it can't be null so we do not need add NOT NULL for early NULL filtering.
-
- 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.
-