mariadb

Tree: 68baf07dcd

Author	SHA1	Message	Date
Igor Babaev	66bd2b56fc	Fixed LP bug #1058071 (mdev-564). 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.	13 years ago
Igor Babaev	8e95e6543b	Changed a test case from join_cache.test to make it platform independent	14 years ago
Igor Babaev	4dc963a9f3	Fixed LP bug #999251 : Q13 from DBT3 uses table scan instead of covering index scan. The optimizer chose a less efficient execution plan due to the following defects of the code: 1. the generic handler function handler::keyread_time did not take into account that in clustered primary keys record data is included into each index entry 2. the function make_join_readinfo erroneously decided that index only scan could not be used if join cache was empoyed. Added no additional test case. Adjusted some of the test results.	14 years ago
Sergei Golubchik	580eca69ae	typo fixed: space in the status variable name	14 years ago
Sergey Petrunya	2a16e7674b	BUG#913030: Optimizer chooses a suboptimal excution plan for Q18 from DBT-3 - When doing join optimization, pre-sort the tables so that they mimic the execution order we've had with 'semijoin=off'. - That way, we will not get regressions when there are two query plans (the old and the new) that have indentical costs but different execution times (because of factors that the optimizer was not able to take into account).	14 years ago
Igor Babaev	6f3c39a057	Fixed LP bug #944782 . This bug in the function JOIN::drop_unused_derived_keys() could leave the internal structures for a materialized derived table in an inconsistent state. This led to a not quite correct EXPLAIN output when no additional key had been created to access the table. It also may lead to more serious consequences: so, the test case added with this fix caused a crash in mariadb-5.5.20.	14 years ago
unknown	c299e027ee	Changed names of statistic variables and counting matches instaed of rejected rows.	14 years ago
unknown	607aab9c1d	Counters for Index Condition Pushdown added (MDEV-130).	14 years ago
Igor Babaev	c8bbe06ac7	Fixed LP bug #925985 . If the flag 'optimize_join_buffer_size' is set to 'off' and the value of the system variable 'join_buffer_size' is greater than the value of the system variable 'join_buffer_space_limit' than no join cache can be employed to join tables of the executed query. A bug in the function JOIN_CACHE::alloc_buffer allowed to use join buffer even in this case while another bug in the function revise_cache_usage could cause a crash of the server in this case if the chosen execution plan for the query contained outer join or semi-join operation.	14 years ago
Igor Babaev	5ca1dd8f0b	Fixed LP bug #922971 . Applied the fix for bug #12546542 from the mysql-5.6 code line: JOIN_CACHE::join_records forgot to reset JOIN_TAB::first_unmatched in some cases.	14 years ago
Igor Babaev	80009f5862	Back-ported test cases for bugs #53060 , #53305 , #50358 , #49453 from subquery_sj of mysql-5.6 code line. The bugs could not be reproduced in the latest release of mariadb-5.3 as they were fixed either when the code of subquery optimization was back-ported from mysql-6.0 or later when some other bugs were fixed.	14 years ago
Igor Babaev	c583aaf56b	Changed a test case from join_cache.test to make it platform independent.	14 years ago
Igor Babaev	2b1f0b8757	Back-ported the patch of the mysql-5.6 code line that 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.	14 years ago
Igor Babaev	a910e8ef5b	Made join_cache_level == 2 by default.	14 years ago
Igor Babaev	fa29f18ffb	Fixed LP bug #901478 . If the duplicate elimination strategy is used for a semi-join and potentially one of the block-based join algorithms can be employed to join the inner tables of the semi-join then sorting of the head (first non-constant) table for a query with ORDER BY / GROUP BY cannot be used.	14 years ago
Igor Babaev	7414a0b6d6	Fixed LP bug #900469 . The execution plan cannot use sorting on the first table from the sequence of the joined tables if it plans to employ the block-based hash join algorithm.	14 years ago
Igor Babaev	b4c9fa321d	Fixed LP bug #899509 . The optimizer must ignore any possible hash join key when looking for the query execution plan with join_cache_level set to 0.	14 years ago
Igor Babaev	7d1f41265c	Fixed LP bug #899777 . KEYUSE elements for a possible hash join key are not sorted by field numbers of the second table T of the hash join operation. Besides some of these KEYUSE elements cannot be used to build any key as their key expressions depend on the tables that are planned to be accessed after the table T. The code before the patch did not take this into account and, as a result, execition of a query the employing block-based hash join algorithm could cause a crash or return a wrong result set.	14 years ago
Sergey Petrunya	aa98fe3a7a	Update test results	14 years ago
Igor Babaev	c05e5b9c65	Fixed LP bug #887479 . The function setup_semijoin_dups_elimination erroneously assumed that if join_cache_level is set to 3 or 4 then the type of the access to a table cannot be JT_REF or JT_EQ_REF. This could lead to wrong query result sets.	14 years ago
Igor Babaev	e0c1b3f242	Fixed LP bug #886145 . 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 .	14 years ago
Igor Babaev	1c47e1ca0d	Made the result test of a test case platform independent (correction for the previous patch).	14 years ago
Igor Babaev	3c3a1fbdcd	Made the result test of a test case platform independent.	14 years ago
Igor Babaev	a55f0cabcb	Fixed a bad merge. Changed a test case to make its result set platform independent.	14 years ago
Igor Babaev	715dc5f99d	Fixed a cost estimation bug introduced into in the function best_access_path 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.	14 years ago
Igor Babaev	63abf00a62	Made the optimizer switches 'derived_merge' and 'derived_with_keys' off by default.	15 years ago
Igor Babaev	03081bc1fd	Changed the default setting of the optimizer switch 'optimize_join_buffer_size'. Made it 'off' by default.	15 years ago
Igor Babaev	5ead4083ec	Fixed LP bug #806510 . 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.	15 years ago
Sergey Petrunya	1492de8563	Set the default to be mrr=off,mrr_sort_keys=off: - 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	15 years ago
Sergey Petrunya	c1de6f8b77	Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.	15 years ago
Igor Babaev	31edda66fd	Fixed LP bug #802860 . This crashing bug could manifest itself at execution of join queries over materialized derived tables with IN subquery predicates in the where clause. If for such a query the optimizer chose to use duplicate weed-out with duplicates in a materialized derived table and chose to employ join cache the the execution could cause a crash of the server. It happened because the JOIN_CACHE::init method assumed that the value of TABLE::file::ref is set at the moment when the method was called for the employed join cache. It's true for regular tables, but it's not true for materialized derived tables that are filled now at the first access to them, i.e. after the JOIN_CACHE::init has done its job. To fix this problem for any ROWID field of materialized derived table the procedure that copies fields from record buffers into the employed join buffer first checks whether the value of TABLE::file::ref has been set for the table, and if it's not so the procedure sets this value.	15 years ago
Sergei Golubchik	0accbd0364	lots of post-merge changes	15 years ago
Sergey Petrunya	997445bc8e	Make EXPLAIN better at displaying MRR/BKA: - "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.	15 years ago
Vladislav Vaintroub	9e5bf5ae0c	Suppress ANALYZE_TABLE output, to be consistent with rest of the test case	15 years ago
Igor Babaev	6cd1ec3b6b	Moved the test case for LP bug 725050 into a new test file.	15 years ago
Igor Babaev	0f0360e21f	Fixed LP bug #725050 . The bug in the function print_keyuse() caused crashes if hash join could be used. It happened because the function ignored the fact that KEYUSE structures could be created for hash joins as well.	15 years ago
Igor Babaev	8f4bcdace0	Made a newly added EXPLAIN platform independent.	15 years ago
Igor Babaev	272e5e6212	BNLH algorithm always used a full table scan over the joined table 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.	15 years ago
Sergey Petrunya	5ed10efc7b	Update the test results back (were changed due to slightly different QEPs produced by the optimizer, which was an error, which was detected and fixed)	15 years ago
Sergey Petrunya	e69c642920	Post-merge fixes part 5	15 years ago
Igor Babaev	d492903502	Fixed LP bug #707827 . This bug could manifest itself when hash join over a varchar column with NULL values in some rows was used. It happened because the function key_buf_cmp erroneously returned FALSE when one of the joined key fields was null while the second was not. Also fixed two other bugs in the functions key_hashnr and key_buf_cmp that could possibly lead to wrong results for some queries that used hash join over several columns with nulls. Also reverted the latest addition of the test case for bug #45092. It had been already backported earlier.	15 years ago
Igor Babaev	edeeb023bc	Post-second-review fixes for the patch that added the code allowing to use hash join over equi-join conditions without supporting indexes.	15 years ago
Igor Babaev	84a0c9b2a2	Fixed LP bug #698882 . 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.	15 years ago
Sergey Petrunya	26599d9260	Backport testcase for: Bug #45092: join buffer contains two blob columns one of which is used in the key employed to access the joined table	15 years ago
Igor Babaev	cb4fa7f401	Fixed LP bug #697557 . When stored in a key buffer any varchar field has a length prefix that always takes 2 bytes.	15 years ago
Igor Babaev	af800fd92f	The patch adds the code that allows to use equi-join conditions for hash join in the cases when there are no suitable indexes for these conditions.	15 years ago
Igor Babaev	77cbad4b31	Corrected the test case for bug 695304. Added a test case for bug #695442 - a duplicate of bug 694092.	15 years ago
Igor Babaev	18dc64eca2	Fixed LP bug #694443 . One of the hash functions employed by the BNLH join algorithm calculates the the value of hash index for key value utilizing every byte of the key buffer. To make this calculation valid one has to ensure that for any key value unused bytes of the buffer are filled with with a certain filler. We choose 0 as a filler for these bytes. Added an optional boolean parameter with_zerofill to the function key_copy. If the value of the parameter is TRUE all unused bytes of the key buffer is filled with 0.	15 years ago
Igor Babaev	d9a81475c7	Fixed LP bug#694092. In some cases the function make_cond_for_index() was mistaken when detecting index only pushdown conditions for a table: a pushdown condition that was not index only could be marked as such. It happened because the procedure erroneously used the markers for index only conditions that remained from the calls of this function that extracted the index conditions for other tables. Fixed by erasing index only markers as soon as they are need anymore.	15 years ago
Igor Babaev	a095346a9d	Fixed LP bug #670380 . Lifted the limitation that hash join could not be used over varchar fields with non-binary collation.	15 years ago

1 2

91 Commits (68baf07dcd985376fae9d24c12ee0ff560b61e8f)