-
Praveenkumar Hulakund authored
definitions aren't cached Analysis: ---------- Whenever view is opened, the view definition is read from the .frm file of view. And then this definition is used by the File_parser. Reading definition from .frm file every time is one of the main reason of performance bottleneck. Fix: ---------- When view is opened for the first time, TABLE_SHARE is created for it (But no open count is mentioned for it). The TABLE_SHARE for view is available in the table share cache till there is enough space. Till its in the table share cache, same TABLE_SHARE of view is used. To avoid reading view definition from the file every time, added new member in TABLE_SHARE to cache File_parser object for the view's .FRM file. So that next access to the same TABLE_SHARE need not have to read the definition from .FRM, but instead can reuse definition stored in the File_parser object. To verify the improvement in the performance, I used the same stored procedure provided in this report. Executed p1(100000) with view "v1" (say A) and p1(100000) with table "t1" (say B), with and without this fix. Delay in execution of A compared to B without fix= ~3.99 secs with fix= ~1.66 secs Improvement in performance = ~58.39% We also tried to cache results of a later stage of view processing, i.e. cache results of File_parser::parse() call, but straight forward implementation of this approach didn't bring any noticiable improvement
Praveenkumar Hulakund authoreddefinitions aren't cached Analysis: ---------- Whenever view is opened, the view definition is read from the .frm file of view. And then this definition is used by the File_parser. Reading definition from .frm file every time is one of the main reason of performance bottleneck. Fix: ---------- When view is opened for the first time, TABLE_SHARE is created for it (But no open count is mentioned for it). The TABLE_SHARE for view is available in the table share cache till there is enough space. Till its in the table share cache, same TABLE_SHARE of view is used. To avoid reading view definition from the file every time, added new member in TABLE_SHARE to cache File_parser object for the view's .FRM file. So that next access to the same TABLE_SHARE need not have to read the definition from .FRM, but instead can reuse definition stored in the File_parser object. To verify the improvement in the performance, I used the same stored procedure provided in this report. Executed p1(100000) with view "v1" (say A) and p1(100000) with table "t1" (say B), with and without this fix. Delay in execution of A compared to B without fix= ~3.99 secs with fix= ~1.66 secs Improvement in performance = ~58.39% We also tried to cache results of a later stage of view processing, i.e. cache results of File_parser::parse() call, but straight forward implementation of this approach didn't bring any noticiable improvement
Loading