1. 24 Jun, 2018 1 commit
  2. 20 Jun, 2018 5 commits
  3. 19 Jun, 2018 3 commits
  4. 13 Jun, 2018 3 commits
  5. 12 Jun, 2018 4 commits
  6. 11 Jun, 2018 4 commits
  7. 10 Jun, 2018 15 commits
  8. 09 Jun, 2018 1 commit
    • Varun Gupta's avatar
      MDEV-16374: Filtered shows 0 for materilization scan for a semi join, which... · cd33280b
      Varun Gupta authored
      MDEV-16374: Filtered shows 0 for materilization scan for a semi join, which makes optimizer always picks
      materialization scan over materialization lookup
      
      For non-mergeable semi-joins we don't store the estimates of the IN subquery in table->file->stats.records.
      In the function TABLE_LIST::fetch_number_of_rows, we store the number of rows in the tables
      (estimates in case of derived table/views).
      Currently we don't store the estimates for non-mergeable semi-joins, which leads to a problem of selecting
      materialization scan over materialization lookup.
      Fixed this by storing these estimated appropriately
      cd33280b
  9. 08 Jun, 2018 3 commits
  10. 07 Jun, 2018 1 commit
    • Chris Calender's avatar
      MDEV-15789 - mysqlslap use incorrect table def · d9b159a2
      Chris Calender authored
      The bug arises when one uses --auto-generate-sql-guid-primary (and
      --auto-generate-sql-secondary-indexes) with mysqlslap and also have
      sql_mode=STRICT_TRANS_TABLE.
      
      When using this option, mysqlslap should create a column with varchar(36),
      but it appears to create it as a varchar(32) only. Then if one has
      sql_mode=STRICT_TRANS_TABLES, it throws an error, like:
      
        mysqlslap: Cannot run query INSERT INTO t1 VALUES (...)
        ERROR : Data too long for column 'id' at row 1
      
      Upstream bug report: BUG#80329.
      d9b159a2