Thoughts on the new PERFORMANCE_SCHEMA in MySQLSun, Feb 8, 2009 in Databases
Peter Gulutzan and Mark Leith have both written about the new PERFORMANCE_SCHEMA in MySQL. I’ve read through the worklog, or most of it – there were some spots where Firefox seemed to start overlaying parts with other parts, quite weird. But anyway I’ve read as much as I can.
Obviously many people have been putting a ton of thought into this for years, and I can’t pretend to judge their work in a single sitting. But I have opinions nevertheless.
If the implementation turns out to be as good as the initial swing at it looks, this is a great development. This is the way things should be done – this is, finally, the level of detail of instrumentation other databases have. There’s a lot of complexity; it is a large worklog and I can’t say whether it’s complete or something is put in the wrong place or will turn out to be not quite what’s needed; that’s where I stop trying to form an opinion. But overall, this is just a great development.
A few questions and comments, though.
- Why has this not been public? You put four years of work into this without any community input? What a shame.
- Mark says “There’s no stats for InnoDB yet, though I can’t see that lasting for long.” I can. Why don’t you see InnoDB being slow to add support for it?
- What version is this intended for? 6.x is kind of vague after four years of work.
- Information by itself is no use unless you can act on it. I predict that a lot of neglected bug reports will get revisited if this information can be brought to bear on it. I also predict that if implemented fully, this will show people where the hot spots in their server are; and yet they’ll be unable to fix them.
About The Author
Baron is the founder and CEO of VividCortex. He is the author of High Performance MySQL and many open-source tools for performance analysis, monitoring, and system administration. Baron contributes to various database communities such as Oracle, PostgreSQL, Redis and MongoDB.