1. 16 Apr, 2014 1 commit
  2. 15 Apr, 2014 1 commit
  3. 11 Apr, 2014 1 commit
    • Sergey Petrunya's avatar
      MDEV-6081: ORDER BY+ref(const): selectivity is very incorrect (MySQL Bug#14338686) · 244d4b53
      Sergey Petrunya authored
      Add a testcase and backport this fix:
      
      Bug#14338686: MYSQL IS GENERATING DIFFERENT AND SLOWER
                    (IN NEWER VERSIONS) EXECUTION PLAN
      PROBLEM:
      While checking for an index to sort for the order by clause
      in this query
      "SELECT datestamp FROM contractStatusHistory WHERE
      contract_id = contracts.id ORDER BY datestamp asc limit 1;"
      
      we do not calculate the number of rows to be examined correctly.
      As a result we choose index 'idx_contractStatusHistory_datestamp'
      defined on the 'datestamp' field, rather than choosing index
      'contract_id'. And hence the lower performance.
      
      ANALYSIS:
      While checking if an index is present to give the records in
      sorted order(datestamp), we consider the selectivity of the
      'ref_key'(contract_id here) using 'table->quick_condition_rows'.
      'ref_key' here can be an index from 'REF_ACCESS' or from 'RANGE'.
      
      As this is a 'REF_ACCESS', 'table->quick_condition_rows' is not
      set to the actual value which is 2. Instead is set to the number
      of tuples present in the table indicating that every row that
      is selected would be satisfying the condition present in the query.
      
      Hence, the selectivity becomes 1 even when we choose the index
      on the order by column instead of the join_condition.
      
      But, in reality as only 2 rows satisy the condition, we need to
      examine half of the entire data set to get one tuple when we
      choose index on the order by column.
      Had we chosen the 'REF_ACCESS' we would have examined only 2 tuples.
      Hence the delay in executing the query specified.
        
      FIX:
      While calculating the selectivity of the ref_key:
      For REF_ACCESS consider quick_rows[ref_key] if range 
      optimizer has an estimate for this key. Else consider 
      'rec_per_key' statistic.
      For RANGE ACCESS consider 'table->quick_condition_rows'.
      244d4b53
  4. 07 Apr, 2014 1 commit
  5. 10 Apr, 2014 4 commits
    • Elena Stepanova's avatar
      MDEV-6068 Upgrade removes all changes to 'mysql' database · a7962ea5
      Elena Stepanova authored
      10.0 variation of the problem was that system tables were altered
      during mysql_upgrade process using old (smaller) column lengths. 
      At the end the tables were altered again, so the structure was restored,
      but if there were long values before the upgrade, they were truncated.
      Fixed by using correct column length in alter statements.
      a7962ea5
    • Alexander Barkov's avatar
      Fixing compilation problem on AIX. · 5fffa449
      Alexander Barkov authored
      5fffa449
    • unknown's avatar
      MDEV-5401: Wrong result (missing row) on a 2nd execution of PS with... · 39afdcdd
      unknown authored
      MDEV-5401: Wrong result (missing row) on a 2nd execution of PS with exists_to_in=on, MERGE view or a SELECT SQ
      
      The problem was that the view substitute its fields (on prepare) with reverting the change after execution. After prepare on optimization exists2in convertion substituted arguments of '=' with constsnt '1', but then one of the arguments of '=' was reverted to the view field reference.This lead to incorrect WHERE condition on the second execution.
      
      To fix the problem we replace whole '=' with '1' permannently.
      39afdcdd
    • unknown's avatar
      MDEV-6040: MariaDB hangs if terminated quickly after start · 584c2d0a
      unknown authored
      We need to use mysql_cond_broadcast() rather than _signal for
      COND_thread_count, as there can be multiple waiters.
      
      Thanks to Pavel Ivanov for reporting both the problem and the
      solution.
      584c2d0a
  6. 09 Apr, 2014 1 commit
  7. 02 Apr, 2014 1 commit
  8. 01 Apr, 2014 1 commit
    • Sergey Petrunya's avatar
      MDEV-5992: EITS: Selectivity of non-indexed condition is counted twice in table's fanout · 26a3d567
      Sergey Petrunya authored
      MDEV-5984: EITS: Incorrect filtered% value for single-table select with range access
      - Fix calculate_cond_selectivity_for_table() to work correctly with range accesses 
        over multi-component keys:
        = First, take selectivity of all possible range scans into account. Remember which 
          fields were used bt the range scans.
        = Then, calculate selectivity produced by sargable predicates on fields. If a 
          field was used in a possible range access, assume its selectivity is already
          taken into account.
      - Fix table_cond_selectivity(): when quick select is used, selectivity of
        COND(table) is taken into account in matching_candidates_in_table(). In
        table_cond_selectivity() we should not apply it for the second time.
      26a3d567
  9. 31 Mar, 2014 2 commits
  10. 29 Mar, 2014 6 commits
  11. 28 Mar, 2014 8 commits
  12. 27 Mar, 2014 13 commits