- 27 Jan, 2012 1 commit
-
-
Sergey Petrunya authored
BUG#922254: Assertion `0' failed at item_cmpfunc.cc:5899: Item* Item_equal::get_first(JOIN_TAB*, Item*) Fixed Item* Item_equal::get_first(JOIN_TAB *context, Item *field_item) to work correctly in the case where: - context!= NO_PARTICULAR_TAB, it points to a table within SJ-Materialization nest - field_item points to an item_equal that has a constant Item_field but does not have any fields from tables that are within semi-join nests.
-
- 26 Jan, 2012 2 commits
-
-
Sergey Petrunya authored
QUERY_CACHE_DB_LENGTH_SIZE 0, just like it is done with QUERY_CACHE_FLAGS_SIZE.
-
Sergey Petrunya authored
-
- 25 Jan, 2012 4 commits
-
-
Sergey Petrunya authored
- Disable use of join cache when we're using FirstMatch strategy, and the join order is such that subquery's inner tables are interleaved with outer. Join buffering code is incapable of handling such join orders. - The testcase requires use of @@debug_optimizer_prefer_join_prefix to hit the bug, but I'm pushing it anyway (including the mention of the variable in .test file), so that it can be found and enabled when/if we get something comparable in the main tree.
-
Sergey Petrunya authored
-
Sergey Petrunya authored
The problem was that LooseScan execution code assumed that tab->key holds the index used for looseScan. This is only true when range or full index scan are used. In case of ref access, the index is in tab->ref.key (and tab->index==0 which explains how LooseScan passed tests with ref access: they used one index) Fixed by setting/using loosescan_key, which always the correct index#.
-
Sergey Petrunya authored
-
- 23 Jan, 2012 2 commits
-
-
Sergey Petrunya authored
Handler_mrr_extra_key_sorts.
-
unknown authored
-
- 22 Jan, 2012 2 commits
-
-
Igor Babaev authored
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.
-
Igor Babaev authored
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.
-
- 19 Jan, 2012 3 commits
-
-
Sergey Petrunya authored
- equality substitution code was geared towards processing WHERE/ON clauses. that is, it assumed that it was doing substitions on the code that = wasn't attached to any particular join_tab yet = was going to be fed to make_join_select() which would take the condition apart and attach various parts of it to tables inside/outside semi-joins. - However, somebody added equality substition for ref access. That is, if we have a ref access on TBL.key=expr, they would do equality substition in 'expr'. This possibility wasn't accounted for. - Fixed equality substition code by adding a mode that does equality substition under assumption that the processed expression will be attached to a certain particular table TBL.
-
Sergey Petrunya authored
- setup_semijoin_dups_elimination() would incorrectly set join_tab->do_firstmatch when the join order had outer tables interleaved with inner.
-
Vladislav Vaintroub authored
-
- 18 Jan, 2012 6 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Igor Babaev authored
If the expression for a derived table of a query contained a LIMIT clause the estimate of the number of rows in this derived table returned by the EXPLAIN command could be badly off since the optimizer ignored the limit number from the LIMIT clause when getting the estimate. The call of the method SELECT_LEX_UNIT->set_limit added in the code of mysql_derived_optimize() will be needed also in maria-5.5 where parameters in the LIMIT clause are supported.
-
unknown authored
handler counter Handler_read_rnd_deleted.
-
- 17 Jan, 2012 1 commit
-
-
unknown authored
Removed unused code merged from 5.2. In 5.3 we fix this problem by checking if we put max/min group function without GROUP BY artificially in case of MODE_ONLY_FULL_GROUP_BY sql mode.
-
- 13 Jan, 2012 1 commit
-
-
Michael Widenius authored
-
- 11 Jan, 2012 1 commit
-
-
unknown authored
-
- 10 Jan, 2012 2 commits
-
-
unknown authored
Fix for LP BUG#908269 Wrong result with subquery in select list, EXISTS, constant MyISAM/Aria table. Problem: When building the condition for JOIN::outer_ref_cond the optimizer forgot to take into account that this condition could depend on constant tables as well.
-
Sergey Petrunya authored
-
- 09 Jan, 2012 1 commit
-
-
Michael Widenius authored
mysql-test/r/information_schema_all_engines.result: Update result mysql-test/t/information_schema_all_engines.test: Added --sorted-results as tables in information_schema are not sorted.
-
- 08 Jan, 2012 2 commits
-
-
Vladislav Vaintroub authored
Split IO threads into ones that handle only read completion and ones that handle only write completion, as it was originally done, but got lost with "completion port" patch. The reason we need to have dedicated read and dedicated write threads is that read completion routine can block waiting for write io to complete, and in rare cases where all io threads are handling async reads, it can deadlock.
-
Sergey Petrunya authored
- Create/use do_copy_nullable_row_to_notnull() function for ref access, which is used when copying from not-NULL field in table that can be NULL-complemented to not-NULL field.
-
- 03 Jan, 2012 1 commit
-
-
Igor Babaev authored
The patch for bug 685411 erroneously removed a call of engine->set_thd() from Item_subselect::fix_fields().
-
- 30 Dec, 2011 3 commits
-
-
Sergey Petrunya authored
-
unknown authored
-
Sergey Petrunya authored
-
- 29 Dec, 2011 1 commit
-
-
Sergey Petrunya authored
from a heap temptable, which uses pointers to records (that is, byte* pointers) as rowids. This meant that for rows with the same sort key value, the order was determined by memory layout.
-
- 28 Dec, 2011 1 commit
-
-
Sergey Petrunya authored
-
- 27 Dec, 2011 1 commit
-
-
Sergey Petrunya authored
-
- 26 Dec, 2011 1 commit
-
-
Igor Babaev authored
-
- 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.
-
- 20 Dec, 2011 2 commits
-
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
- 19 Dec, 2011 1 commit
-
-
unknown authored
The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
-