1. 13 Apr, 2015 1 commit
  2. 12 Apr, 2015 9 commits
  3. 31 Mar, 2015 1 commit
  4. 29 Mar, 2015 1 commit
  5. 23 Mar, 2015 1 commit
  6. 20 Mar, 2015 1 commit
    • Vicențiu Ciorbaru's avatar
      MDEV-7682 Incorrect use of SPATIAL KEY for query plan · 9253064c
      Vicențiu Ciorbaru authored
      If the spatial key is used within an equality comparison, the comparison
      does not produce relevant results generally as identical geometry can be
      stored differently. Still, we want to support the operation. In order
      to allow a hash join plan, we must define a key_length for Field_geom.
      9253064c
  7. 19 Mar, 2015 1 commit
  8. 17 Mar, 2015 1 commit
    • Sergei Petrunia's avatar
      MDEV-7474: Semi-Join's DuplicateWeedout strategy skipped ... · c020d362
      Sergei Petrunia authored
      JOIN::cur_dups_producing_tables was not maintained correctly in
      the cases of greedy optimization (search_depth < n_tables).
      
      Moved it to POSITION structure where it will be maintained automatically.
      
      Removed POSITION::prefix_dups_producing_tables since its value can now
      be calculated.
      c020d362
  9. 12 Mar, 2015 1 commit
  10. 09 Mar, 2015 1 commit
  11. 06 Mar, 2015 4 commits
  12. 05 Mar, 2015 1 commit
    • Jan Lindström's avatar
      MDEV-7578 :Slave is ~10x slower to execute set of statements compared to master when using RBR · f66fbe8c
      Jan Lindström authored
      Analysis: On master when executing (single/multi) row INSERTs/REPLACEs
      InnoDB fallback to old style autoinc locks (table locks)
      only if another transaction has already acquired the AUTOINC lock.
      Instead on slave as we are executing log_events and sql_command
      is not correctly set, InnoDB does not use new style autoinc
      locks when it could.
      
      Fix: Use new style autoinc locks also when
      thd_sql_command(user_thd) == SQLCOM_END i.e. this is RBR event.
      f66fbe8c
  13. 28 Feb, 2015 1 commit
    • Vicențiu Ciorbaru's avatar
      MDEV-6838: Using too big key for internal temp tables · 45b6edb1
      Vicențiu Ciorbaru authored
      This bug manifests due to wrong computation and evaluation of
      keyinfo->key_length. The issues were:
      * Using table->file->max_key_length() as an absolute value that must not be
        reached for a key, while it represents the maximum number of bytes
        possible for a table key.
      * Incorrectly computing the keyinfo->key_length size during
        KEY_PART_INFO creation. The metadata information regarding the key
        such the field length (for strings) was added twice.
      45b6edb1
  14. 27 Feb, 2015 1 commit
  15. 23 Feb, 2015 1 commit
  16. 13 Feb, 2015 1 commit
  17. 12 Feb, 2015 1 commit
  18. 11 Feb, 2015 5 commits
  19. 10 Feb, 2015 2 commits
  20. 09 Feb, 2015 2 commits
  21. 11 Feb, 2015 1 commit
  22. 10 Feb, 2015 2 commits