-
Dmitry Lenev authored
FOR CERTAIN QUERIES TO INFORMATION_SCHEMA". The problem was that metadata locking subsystem introduced too much overhead for queries to I_S which were processed by opening only .FRM or .TRG files and had to scanned a lot of tables (e.g. SELECT COUNT(*) FROM I_S.TRIGGERS was affected). The same effect was not observed for similar queries which performed full-blown table open in order to fill I_S table. The problem stemmed from the fact that in case when I_S implementation opened only .FRM or .TRG file for each table processed it didn't release metadata lock it has acquired on the table after finishing its processing. As result, list of acquired metadata locks were growing until the end of statement. Since acquisition of each new lock required search in the list of already acquired locks performance degraded. The same effect is not observed when I_S implementation performs full-blown table open for each table being processed, as in the latter cases metadata lock on the table is released right after table processing. This fix addressed the problem by ensuring that I_S implementation releases metadata lock after processing the table in both cases of full-blown table open and in case when only .FRM or .TRG file is read. mysql-test/r/information_schema.result: Added coverage for bug #12828477 - "MDL SUBSYSTEM CREATES BIG OVERHEAD FOR CERTAIN QUERIES TO INFORMATION_SCHEMA". mysql-test/t/information_schema.test: Added coverage for bug #12828477 - "MDL SUBSYSTEM CREATES BIG OVERHEAD FOR CERTAIN QUERIES TO INFORMATION_SCHEMA". sql/sql_show.cc: Changed fill_schema_table_from_frm() to release metadata lock it has acquired after processing the .FRM or .TRG file for table. Without this step metadata locks acquired for each table processed will be accumulated. In situation when a lot of tables are processed by I_S query this will result in transaction with too many metadata locks. As result performance of acquisition of new lock will degrade.
46294e22