• Inaam Rana's avatar
    Bug#11759044 - 51325: DROPPING AN EMPTY INNODB TABLE TAKES A LONG TIME · 358a31df
    Inaam Rana authored
    WITH LARGE BUFFER POOL
    
    (Note: this a backport of revno:3472 from mysql-trunk)
    
    rb://845
    approved by: Marko
    
      When dropping a table (with an .ibd file i.e.: with
      innodb_file_per_table set) we scan entire LRU to invalidate pages from
      that table. This can be painful in case of large buffer pools as we hold
      the buf_pool->mutex for the scan. Note that gravity of the problem does
      not depend on the size of the table. Even with an empty table but a
      large and filled up buffer pool we'll end up scanning a very long LRU
      list.
      
      The fix is to scan flush_list and just remove the blocks belonging to
      the table from the flush_list, marking them as non-dirty. The blocks
      are left in the LRU list for eventual eviction due to aging. The
      flush_list is typically much smaller than the LRU list but for cases
      where it is very long we have the solution of releasing the
      buf_pool->mutex after scanning 1K pages.
      
      buf_page_[set|unset]_sticky(): Use new IO-state BUF_IO_PIN to ensure
      that a block stays in the flush_list and LRU list when we release
      buf_pool->mutex. Previously we have been abusing BUF_IO_READ to achieve
      this.
    358a31df
innodb_cmp_drop_table.result 468 Bytes