Bug #56846 Performance of ha_check_if_table_exists() is not the best
Submitted: 17 Sep 2010 16:26 Modified: 17 Sep 2010 19:28
Reporter: Kevin Lewis Email Updates:
Status: Verified Impact on me:
Category:MySQL Server: Storage Engine API Severity:S3 (Non-critical)
Version:next-mr OS:Any
Assigned to: CPU Architecture:Any

[17 Sep 2010 16:26] Kevin Lewis
While merging mysql-next-mr to mysql-next-mr-wl5308, I noticed a new call to ha_discover() in the new function ha_check_if_table_exits().  This is not the most efficient way to determine if a table exists within an engine since it returns a fill FRM.  This new function just ignores that FRM.  ha_discover is supported by NDB and ARCHIVE storage engines.  A more efficient method is to call the existing interface ha_table_exists_in_engine().  This existing interface is designed to return only a boolean.  It asks each plugin to do a lightweight search for the schema_name/table_name.  It follows the same approach as ha_discover; for each plugin, call table_exists_in_engine_handlerton(), which calls a handlerton::table_exists_in_engine() if that function is provided by the plugin.

The only problem is that this interface in not supported by ARCHIVE.  That's why it was not used initially.  

How to repeat:
Code inspection

Suggested fix:
We need to add support for handlerton::table_exists_in_engine() to ha_archive.cc and use this existing lightweight handler interface in the new function ha_check_if_table_exists() or instead of it.  The call to ha_discover() is too expensive.
[17 Sep 2010 19:28] Sveta Smirnova
Thank you for the report.

Verified as described.