dict_table_close() is a performance hog

In an email exchange with maxk, the following performance bottleneck was mentioned:

/** Decrement the count of open handles */

void dict_table_close(dict_table_t *table)

{

  if (table->get_ref_count() == 1 &&

      dict_stats_is_persistent_enabled(table) &&

      strchr(table->name.m_name, '/'))

  {

    /* It looks like we are closing the last handle. The user could

    have executed FLUSH TABLES in order to have the statistics reloaded

    from the InnoDB persistent statistics tables. We must acquire

    exclusive dict_sys.latch to prevent a race condition with another

    thread concurrently acquiring a handle on the table. */

    dict_sys.lock(SRW_LOCK_CALL);

    if (table->release())

    {

      table->stats_mutex_lock();

      if (table->get_ref_count() == 0)

        dict_stats_deinit(table);

      table->stats_mutex_unlock();

    }

    dict_sys.unlock();

  }

  else

    table->release();

}

The intention of the exclusive dict_sys.latch is to prevent concurrent ha_innobase::open() from accessing a table whose statistics have been deinitialized when the last handle is being closed.

I am thinking that we should replace this obscure logic that is intended to react on FLUSH TABLES with an additional function that would only be executed as part of FLUSH TABLES right after all table handles have been closed. That function could then acquire exclusive dict_sys.latch and invalidate the cached InnoDB persistent statistics for all tables whose reference count is 0. The intention here is to allow users to force a re-read of mysql.innodb_index_stats and mysql.innodb_tables_stats after they were modified by the DBA.