An error occurred fetching the project authors.
  1. 13 May, 2012 1 commit
    • Sergey Petrunya's avatar
      BUG#998236: Assertion failure or valgrind errors at best_access_path ... · 6d41fa0d
      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).  
       
      6d41fa0d
  2. 19 Apr, 2012 2 commits
    • Sergey Petrunya's avatar
      BUG#978479: Wrong result (extra rows) with... · b9bbe4a1
      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.
      
      b9bbe4a1
    • Sergey Petrunya's avatar
      BUG#978479: Wrong result (extra rows) with... · 994c6db2
      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.
      994c6db2
  3. 02 Apr, 2012 1 commit
    • Sergey Petrunya's avatar
      BUG#913030: Optimizer chooses a suboptimal excution plan for Q18 from DBT-3 · 2a16e767
      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).
        
      2a16e767
  4. 18 Mar, 2012 2 commits
    • Sergey Petrunya's avatar
      BUG#952583: Server crashes in Item_field::fix_after_pullout on INSERT .. SELECT · 91d17a9c
      Sergey Petrunya authored
      - Take into account that there may exist Item_field objects with context==NULL.
      91d17a9c
    • Sergey Petrunya's avatar
      BUG#952372: Server crashes on 2nd execution of PS in find_field_in_tables with... · 5805908b
      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.
      
      5805908b
  5. 25 Feb, 2012 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #939009. · 841a74a4
      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.  
      841a74a4
  6. 30 Jan, 2012 1 commit
  7. 28 Jan, 2012 1 commit
  8. 25 Jan, 2012 2 commits
    • Sergey Petrunya's avatar
      BUG#920713: Wrong result (missing rows) with firstmatch+BNL, IN subquery, ... · 424f56b3
      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.
      424f56b3
    • Sergey Petrunya's avatar
      BUG#920255: Wrong result (extra rows) with loosescan and IN subquery · 73cc529b
      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#.
      73cc529b
  9. 22 Jan, 2012 2 commits
  10. 08 Jan, 2012 1 commit
  11. 24 Dec, 2011 1 commit
    • Igor Babaev's avatar
      Back-ported the patch of the mysql-5.6 code line that · 2b1f0b87
      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.
      2b1f0b87
  12. 15 Dec, 2011 3 commits
  13. 12 Dec, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #901709. · 63d32c11
      Igor Babaev authored
      The cause of the reported assertion failure was a division of a double value by 0. 
      63d32c11
  14. 09 Dec, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #901312. · 8a09adb3
      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.
      8a09adb3
  15. 04 Dec, 2011 1 commit
  16. 26 Nov, 2011 1 commit
  17. 25 Nov, 2011 1 commit
    • Sergey Petrunya's avatar
      Semi-join optimizations code cleanup part 2: · f84dbf4b
      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)
      f84dbf4b
  18. 21 Nov, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #887496. · b2e5a3f6
      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.
      b2e5a3f6
  19. 15 Nov, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #889750. · b4b7d941
      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.
      b4b7d941
  20. 09 Nov, 2011 1 commit
  21. 02 Nov, 2011 1 commit
  22. 25 Oct, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#877288: Wrong result with semijoin + materialization + multipart key · 8e6440df
      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). 
      8e6440df
  23. 05 Oct, 2011 1 commit
  24. 01 Oct, 2011 1 commit
  25. 30 Sep, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#861147: Assertion `fixed == 1' failed in Item_func_eq::val_int() with... · b45beca3
      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.
      b45beca3
  26. 22 Sep, 2011 1 commit
  27. 17 Sep, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG##849717: Crash in Item_func::fix_fields on second execution of a prepared... · 27cd8d7b
      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.
      27cd8d7b
  28. 08 Sep, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#830993: Crash in end_read_record with derived table · 5673aa41
      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.
      5673aa41
  29. 05 Sep, 2011 2 commits
  30. 29 Aug, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#834534: Assertion `0' failed in replace_where_subcondition with semijoin subquery in HAVING · 945a595a
      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
      945a595a
  31. 16 Aug, 2011 1 commit
  32. 09 Aug, 2011 1 commit
  33. 21 Jul, 2011 1 commit