An error occurred fetching the project authors.
- 13 May, 2012 1 commit
-
-
Sergey Petrunya authored
- Let fix_semijoin_strategies_for_picked_join_order() set POSITION::prefix_record_count for POSITION records that it copies from SJ_MATERIALIZATION_INFO::tables. (These records do not have prefix_record_count set, because they are optimized as joins-inside-semijoin-nests, without full advance_sj_state() processing).
-
- 19 Apr, 2012 2 commits
-
-
Sergey Petrunya authored
BUG#978479: Wrong result (extra rows) with derived_with_keys+loosescan+semijoin=ON, materialization=OFF - Part#2: Don't try to construct a LooseScan access on indexes that do not guarantee index-ordered reads.
-
Sergey Petrunya authored
BUG#978479: Wrong result (extra rows) with derived_with_keys+loosescan+semijoin=ON, materialization=OFF Part#1: make EXPLAIN's plan match the one by actual execution: Item_subselect::used_tables() should return the same value irrespectively of whether we're running an EXPLAIN or a SELECT.
-
- 02 Apr, 2012 1 commit
-
-
Sergey Petrunya authored
- 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).
-
- 18 Mar, 2012 2 commits
-
-
Sergey Petrunya authored
- Take into account that there may exist Item_field objects with context==NULL.
-
Sergey Petrunya authored
BUG#952372: Server crashes on 2nd execution of PS in find_field_in_tables with semijoin+materialization - The problem was that convert_subq_to_jtbm() attached the semi-join TABLE_LIST object into the wrong list: they used to attach it to the end of parent_lex->leaf_tables.head()->next_local->...->next_local. This was apparently inccorect, as one can construct an example where JTBM nest is attached to a table that is inside some mergeable VIEW, which breaks (causes crash) for name resolution on the subsequent statement re-execution. - Solution: Attach to the "right" list. The "wording" was copied from st_select_lex::handle_derived.
-
- 25 Feb, 2012 1 commit
-
-
Igor Babaev authored
The result of materialization of the right part of an IN subquery predicate is placed into a temporary table. Each row of the materialized table is distinct. A unique key over all fields of the temporary table is defined and created. It allows to perform key look-ups into the table. The table created for a materialized subquery can be accessed by key as any other table. The function best_access-path search for the best access to join a table to a given partial join. With some where conditions this function considers a possibility of a ref_or_null access. If such access employs the unique key on the temporary table then when estimating the cost this access the function tries to use the array rec_per_key. Yet, such array is not built for this unique key. This causes a crash of the server. Rows returned by the subquery that contain nulls don't have to be placed into temporary table, as they cannot be match any row produced by the left part of the subquery predicate. So all fields of the temporary table can be defined as non-nullable. In this case any ref_or_null access to the temporary table does not make any sense and it does not make sense to estimate such an access. The fix makes sure that the temporary table for a materialized IN subquery is defined with columns that are all non-nullable. The also ensures that any row with nulls returned by the subquery is not placed into the temporary table.
-
- 30 Jan, 2012 1 commit
-
-
Sergey Petrunya authored
- If LooseScan is used with quick select, require that quick select produces data in key order (this disables use of MRR, which can return data in arbitrary order).
-
- 28 Jan, 2012 1 commit
-
-
Igor Babaev authored
not be reproduced in the latest release of mariadb-5.3 as it was was fixed by Sergey Petrunia when working on the problems concerning outer joins within in subqueries converted to semi-joins.
-
- 25 Jan, 2012 2 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
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#.
-
- 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.
-
- 08 Jan, 2012 1 commit
-
-
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.
-
- 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 3 commits
-
-
Sergey Petrunya authored
- Correctly handle plan refinement stage for LooseScan plans: run create_ref_for_key() if LooseScan plan includes a ref access, and if we don't have any fixed key components, switch to a full index scan.
-
Igor Babaev authored
-
Igor Babaev authored
set to 'on' by default.
-
- 12 Dec, 2011 1 commit
-
-
Igor Babaev authored
The cause of the reported assertion failure was a division of a double value by 0.
-
- 09 Dec, 2011 1 commit
-
-
Igor Babaev authored
The function setup_sj_materialization_part1() forgot to set the value of TABLE::map for any materialized IN subquery. This could lead to wrong results for queries with subqueries that were converted to queries with semijoins.
-
- 04 Dec, 2011 1 commit
-
-
Sergey Petrunya authored
in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
-
- 26 Nov, 2011 1 commit
-
-
Igor Babaev authored
and 'derived_with_keys'. Now they are set on by default.
-
- 25 Nov, 2011 1 commit
-
-
Sergey Petrunya authored
- Make EXPLAIN display "Start temporary" at the start of the fanout (it used to display at the first table whose rowid gets into temp. table which is not that useful for the user) - Updated test results (all checked)
-
- 21 Nov, 2011 1 commit
-
-
Igor Babaev authored
This bug in the function Loose_scan_opt::check_ref_access_part1 could lead to choosing an invalid execution plan employing a loose scan access to a semi-join table even in the cases when such access could not be used at all. This could result in wrong answers for some queries with IN subqueries.
-
- 15 Nov, 2011 1 commit
-
-
Igor Babaev authored
If the optimizer switch 'semijoin_with_cache' is set to 'off' then join cache cannot be used to join inner tables of a semijoin. Also fixed a bug in the function check_join_cache_usage() that led to wrong output of the EXPLAIN commands for some test cases.
-
- 09 Nov, 2011 1 commit
-
-
unknown authored
-
- 02 Nov, 2011 1 commit
-
-
Sergey Petrunya authored
- Remove the assert in replace_where_subcondition (the patch has explanation why)
-
- 25 Oct, 2011 1 commit
-
-
Sergey Petrunya authored
- when create_ref_for_key() is constructing a ref access for a table that's inside a SJ-Materialization nest, it may not use references to fields of tables that are unside the nest (because these fields will not yet have values when ref access will be used) The check was performed in the first of create_ref_for_key's loops (the one which counts how many key parts are usable) but not in the second (the one which actually fills the TABLE_REF structure).
-
- 05 Oct, 2011 1 commit
-
-
unknown authored
-
- 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.
-
- 30 Sep, 2011 1 commit
-
-
Sergey Petrunya authored
BUG#861147: Assertion `fixed == 1' failed in Item_func_eq::val_int() with semijoin + materialization - convert_subq_to_jtbm() didn't check that subuqery optimization was successful. If it wasn't (in this example because of @@max_join_size violation), it would proceed further and eventually crash when trying to execute the un-optimized subquery.
-
- 22 Sep, 2011 1 commit
-
-
Sergey Petrunya authored
- Provide fix_after_pullout() function for Item_in_optimizer and other Item_XXX classes (basically, all of them that have eval_not_null_tables, which means they have special rules for calculating not_null_tables_cache value)
-
- 17 Sep, 2011 1 commit
-
-
Sergey Petrunya authored
BUG##849717: Crash in Item_func::fix_fields on second execution of a prepared statement with semijoin - If convert_join_subqueries_to_semijoins() decides to wrap Item_in_subselect in Item_in_optimizer, it should do so in prep_on_expr/prep_where, too, as long as they are present. There seems to be two possibilities of how we arrive in this function: - prep_on_expr/prep_where==NULL, and will be set later by simplify_joins() - prep_on_expr/prep_where!=NULL, and it is a copy_and_or_structure()-made copy of on_expr/where. the latter can happen for some (but not all!) nested joins. This bug was that we didn't handle this case.
-
- 08 Sep, 2011 1 commit
-
-
Sergey Petrunya authored
- Let join buffering code correctly take into account rowids needed by DuplicateElimination when it is calculating minimum record sizes. - In JOIN_CACHE::write_record_data, added asserts that prevent us from writing beyond the end of the buffer.
-
- 05 Sep, 2011 2 commits
-
-
Sergey Petrunya authored
- Don't use join buffering for tables that are within ranges that are covered by LooseScan strategy.
-
Sergey Petrunya authored
- get_bound_sj_equalities() would produce incorrect bitmap when non-first equality was bound, which resulted in invalid LooseScan plans.
-
- 29 Aug, 2011 1 commit
-
-
Sergey Petrunya authored
- The problem was that the code that made the check whether the subquery is an AND-part of the WHERE clause didn't work correctly for nested subqueries. In particular, grand-child subquery in HAVING was treated as if it was in the WHERE, which eventually caused an assert when replace_where_subcondition looked for the subquery predicate in the WHERE and couldn't find it there. - The fix: Removed implementation of "thd_marker approach". thd->thd_marker was used to determine the location of subquery predicate: setup_conds() would set accordingly it when making the {where|on_expr}->fix_fields(...) call so that AND-parts of the WHERE/ON clauses can determine they are the AND-parts. Item_cond_or::fix_fields(), Item_func::fix_fields(), Item_subselect::fix_fields (this one was missed), and all other items-that-contain-items had to reset thd->thd_marker before calling fix_fields() for their children items, so that the children can see they are not AND-parts of WHERE/ON. - The "thd_marker approach" required that a lot of code in different locations maintains correct value of thd->thd_marker, so it was replaced with: - The new approach with mark_as_condition_AND_part does not keep context in thd->thd_marker. Instead, setup_conds() now calls {where|on_expr}->mark_as_condition_AND_part() and implementations of that function make sure that: - parts of AND-expressions get the mark_as_condition_AND_part() call - Item_in_subselect objects record that they are AND-parts of WHERE/ON
-
- 16 Aug, 2011 1 commit
-
-
Sergey Petrunya authored
- Make simplify_joins() set maybe_null=FALSE for tables that were on the inner sides of inner joins and then were moved to the inner sides of semi-joins.
-
- 09 Aug, 2011 1 commit
-
-
Igor Babaev authored
Do not optimize derived table for the second time ever.
-
- 21 Jul, 2011 1 commit
-
-
Sergey Petrunya authored
- Correct handling of outer joins + DuplicateWeedout (docs pending)
-