An error occurred fetching the project authors.
  1. 30 Jan, 2012 1 commit
  2. 25 Jan, 2012 2 commits
    • Sergey Petrunya's avatar
      BUG#920713: Wrong result (missing rows) with firstmatch+BNL, IN subquery, ... · 493e4383
      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.
      493e4383
    • Sergey Petrunya's avatar
      BUG#920255: Wrong result (extra rows) with loosescan and IN subquery · 063b6842
      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#.
      063b6842
  3. 19 Jan, 2012 1 commit
  4. 24 Dec, 2011 1 commit
    • Igor Babaev's avatar
      Back-ported the patch of the mysql-5.6 code line that · 1333c9b2
      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.
      1333c9b2
  5. 14 Dec, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#901506: Crash in TABLE_LIST::print on EXPLAIN EXTENDED · 187eacff
      Sergey Petrunya authored
      - Let JTBM optimization code handle the case where the subquery is degenerate and doesn't have a 
        join query plan. Regular materialization would fall back to IN->EXISTS for such cases. Semi-Join
        materialization does not have such option, instead we introduce and use "constant JTBM join tabs".
      187eacff
  6. 12 Dec, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #901709. · f9d2fd6c
      Igor Babaev authored
      The cause of the reported assertion failure was a division of a double value by 0. 
      f9d2fd6c
  7. 11 Dec, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #901478. · 2e527460
      Igor Babaev authored
      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.
      2e527460
  8. 09 Dec, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #901312. · 9e754072
      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.
      9e754072
  9. 08 Dec, 2011 1 commit
    • Sergey Petrunya's avatar
      Small semi-join optimization improvement: · d2929e44
      Sergey Petrunya authored
      - if we're considering FirstMatch access with one inner table, and 
        @@optimizer_switch has semijoin_with_cache flag, calculate costs
        as if we used join cache (because we will be able to do so)
      d2929e44
  10. 07 Dec, 2011 2 commits
  11. 06 Dec, 2011 1 commit
  12. 25 Nov, 2011 4 commits
  13. 24 Nov, 2011 2 commits
    • unknown's avatar
      Fix bug lp:894326 · 70af9cae
      unknown authored
      The patch also fixes an unrelated compiler warning.
      
      Analysis:
      The temporary table created during SJ-materialization
      might be used for sorting for a group by operation. The
      sort buffers for this internal temporary table were not
      cleared by the execution code after each subquery
      re-execution. This resulted in a memory leak detected
      by valgrind.
      
      Solution:
      Cleanup the sort buffers for the semijon tables as well.
      
      
      sql/item_subselect.cc:
        - Fix a compiler warning and add logic to revert to table
          scan partial match when there are more rows in the materialized
          subquery than there can be bits in the NULL bitmap index used
          for partial matching.
      sql/opt_subselect.cc:
        - Fixed a memory leak detected by valgrind
      70af9cae
    • unknown's avatar
      Fix for LP BUG#859375 and LP BUG#887458. · 1a14bdfc
      unknown authored
      Stop attempts to apply IN/ALL/ANY optimizations to so called "fake_select"
      (used for ordering and filtering results of union) in union subquery execution.
      1a14bdfc
  14. 23 Nov, 2011 1 commit
    • Sergey Petrunya's avatar
      Semi-join optimizations code cleanup: · e8cd001b
      Sergey Petrunya authored
      - Break down POSITION/advance_sj_state() into four classes 
        representing potential semi-join strategies.
      
      - Treat all strategies uniformly (before, DuplicateWeedout 
        was special as it was the catch-all strategy. Now, we're 
        still relying on it to be the catch-all, but are able to 
        function,e.g. with firstmatch=on,duplicate_weedout=off.
      
      - Update test results (checked)
      e8cd001b
  15. 18 Nov, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #891995. · 35d51210
      Igor Babaev authored
      This bug in the function setup_semijoin_dups_elimination() could 
      lead to invalid choice of the sequence of tables for which semi-join
      duplicate elimination was applied.
      35d51210
  16. 16 Nov, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #887479. · 57eb3928
      Igor Babaev authored
      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.
      57eb3928
  17. 12 Nov, 2011 2 commits
    • Sergey Petrunya's avatar
      BUG#887468: Second assertion `keypart_map' failed in maria_rkey with semijoin · b54aa084
      Sergey Petrunya authored
      - in advance_sj_state: Do not try to construct LooseScan strategy if we're 
        already behind the last LooseScan table.
      b54aa084
    • unknown's avatar
      Fix MySQL BUG#12329653 · 1eb2eb4b
      unknown authored
      In MariaDB, when running in ONLY_FULL_GROUP_BY mode,
      the server produced in incorrect error message that there
      is an aggregate function without GROUP BY, for artificially
      created MIN/MAX functions during subquery MIN/MAX optimization.
      
      The fix introduces a way to distinguish between artifially
      created MIN/MAX functions as a result of a rewrite, and normal
      ones present in the query. The test for ONLY_FULL_GROUP_BY violation
      now tests in addition if a MIN/MAX function was part of a MIN/MAX
      subquery rewrite.
      
      In order to be able to distinguish these MIN/MAX functions, the
      patch introduces an additional flag in Item_in_subselect::in_strategy -
      SUBS_STRATEGY_CHOSEN. This flag is set when the optimizer makes its
      final choice of a subuqery strategy. In order to make the choice
      consistent, access to Item_in_subselect::in_strategy is provided
      via new class methods.
      ******
      Fix MySQL BUG#12329653
      
      In MariaDB, when running in ONLY_FULL_GROUP_BY mode,
      the server produced in incorrect error message that there
      is an aggregate function without GROUP BY, for artificially
      created MIN/MAX functions during subquery MIN/MAX optimization.
      
      The fix introduces a way to distinguish between artifially
      created MIN/MAX functions as a result of a rewrite, and normal
      ones present in the query. The test for ONLY_FULL_GROUP_BY violation
      now tests in addition if a MIN/MAX function was part of a MIN/MAX
      subquery rewrite.
      
      In order to be able to distinguish these MIN/MAX functions, the
      patch introduces an additional flag in Item_in_subselect::in_strategy -
      SUBS_STRATEGY_CHOSEN. This flag is set when the optimizer makes its
      final choice of a subuqery strategy. In order to make the choice
      consistent, access to Item_in_subselect::in_strategy is provided
      via new class methods.
      1eb2eb4b
  18. 09 Nov, 2011 1 commit
  19. 02 Nov, 2011 1 commit
  20. 18 Oct, 2011 1 commit
  21. 12 Oct, 2011 1 commit
  22. 03 Oct, 2011 1 commit
  23. 30 Sep, 2011 2 commits
    • Sergey Petrunya's avatar
      BUG#861147: Assertion `fixed == 1' failed in Item_func_eq::val_int() with... · 9fd37efb
      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.
      9fd37efb
    • Sergey Petrunya's avatar
      BUG#860553: Crash in create_ref_for_key with semijoin + materialization · 6e236b7b
      Sergey Petrunya authored
      - The problem was that JOIN::save/restore_query_plan() did not save/restore parts of 
        the query plan that are located inside SJ_MATERIALIZATION_INFO structures. This could
        cause parts of one plan to be used with another, which led get_best_combination() to
        constructing non-sensical join plans (and crash).
        Fixed by saving/restoring SJM parts of the query plans.
      
      - check_and_do_in_subquery_rewrites() will not set SUBS_MATERIALIZATION flag when it 
        records that the subquery predicate is to be converted into semi-join. 
        If convert_join_subqueries_to_semijoins() later decides not to convert to semi-join,
        let it set SUBS_MATERIALIZATION flag, if appropriate.
      6e236b7b
  24. 26 Sep, 2011 1 commit
  25. 17 Sep, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG##849717: Crash in Item_func::fix_fields on second execution of a prepared... · b04b47d2
      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.
      b04b47d2
  26. 06 Sep, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#823930: Wrong result with semijoin materialization and blob fields · add730d3
      Sergey Petrunya authored
      - Make subquery_types_allow_materialization() detect a case where 
        create_tmp_table() would create a blob column which would make it 
        impossible to use materialization
        Non-semi-join materialization worked because it detected that this case
        and felt back to use IN->EXISTS. Semi-join Materialization cannot easily
        fallback, so we have to detect this case early.
      add730d3
  27. 05 Sep, 2011 2 commits
  28. 02 Sep, 2011 2 commits
  29. 01 Sep, 2011 1 commit
    • unknown's avatar
      Fix for bug lp:834492 · e681418f
      unknown authored
      Analysis:
      In the test query semi-join merges the inner-most subquery
      into the outer subquery, and the optimization of the merged
      subquery finds some new index access methods. Later the
      IN-EXISTS transformation is applied to the unmerged subquery.
      Since the optimizer is instructed to not consider
      materialization, it reoptimizes the plan in-place to take into
      account the new IN-EXISTS conditions. Just before reoptimization
      JOIN::choose_subquery_plan resets the query plan, which also
      resets the access methods found during the semi-join merge.
      Then reoptimization discovers there are no new access methods,
      but it leaves the query plan in its reset state. Later semi-join
      crashes because it assumes these access methods are present.
      
      Solution:
      When reoptimizing in-place, reset the query plan only after new
      access methods were discovered. If no new access methods were
      discovered, leave the current plan as it was.
      e681418f
  30. 29 Aug, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#834534: Assertion `0' failed in replace_where_subcondition with semijoin subquery in HAVING · 69b68761
      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
      69b68761