Thoughts on the new PERFORMANCE_SCHEMA in MySQL
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.
Hi Baron. I read your blog always interesting and professional blog since years. In your recent posts I wonder why you start getting more and more grumpy.
A year ago you would have just added support to maatkit based on the worklog and blogged about it how cool it is. Instead you write this grumpy post where judge even if you say “I can’t judge …”, where you continue to form a opinion and predict a dark future even if you say “I stop trying to form a opinion”.
I really would like to see you getting back to your old, professional style.
Jan Kneschke
9 Feb 09 at 7:56 am
Really? I thought it was a very positive blog post. I’ve been waiting for this kind of instrumentation, and complaining about its lack (I’ve always been grumpy about that!) for as long as I’ve been working with MySQL. I’ve even tried a couple of times to implement some more features myself; I took a stab at a SHOW LOCKS command for showing InnoDB locks, but had to admit I wasn’t up to the task. I’m really happy about this development, although I am disappointed it’s been kept private. And I didn’t judge what I said I wasn’t going to judge: the completeness etc of the feature.
I think if anything, the same thing happened here that can happen so easily in email — it’s easy to write something that isn’t read the same way I intended it.
But I will take your comment to heart.
Xaprb
9 Feb 09 at 9:23 am
Where are we to discuss things then when we might have a negative opinion? Some of our opinions would be useful to know earlier in the design process, but we are not part of that.
PostgreSQL has a blog and active mailing lists. A lot of technical issues are resolved on the mailing lists and not everything said there is positive. The MySQL mailing lists are dead, except for answers from Sergei and Konstantin.
Mark Callaghan
9 Feb 09 at 10:10 am
@Mark:
FYI, Drizzle is very open about all this stuff, too.
-jay
Jay Pipes
9 Feb 09 at 2:38 pm
Yes, it’s something to be proud of. I much prefer bazaar to cathedral.
Xaprb
9 Feb 09 at 2:58 pm
I can’t seem to find a branch on launchpad for it…
Stewart Smith
10 Feb 09 at 8:52 am
Baron (and Mark),
Though the first paragraphs are positive, the last 4 bullet points are extremely negative. Since you don’t seem to think so, I will point it out to you:
* Why has this not been public? You put four years of work into this without any community input? What a shame.
The positive way to say this is “I wish this would have been public sooner, so the community could have had more input.” Your questions are either passive-aggressive because they’re rhetorical, or would make Peter G. and Mark L. completely defensive as they demand an answer. The “What a shame” is a clear scold, not positive at all.
* 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?
This bullet is condescending. A positive way to say that would be “InnoDB has been slow to add support for many things, I think it’s likely that they’ll be slow to add stats. Is something in the works with InnoDB already?”
* What version is this intended for? 6.x is kind of vague after four years of work.
This would have been completely neutral had it not been for the “after four years of work.” That makes it condescending and snarky. Just “What version is this intended for? 6.x is kind of vague.” would suffice, without the snarkiness.
* 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.
While I’m sure your claims are based in your experiences, this bullet point has no evidence to back it up. In my opinion, “a lot of neglected bug reports will get revisited” is a GOOD thing — Giuseppe begged and pleaded folks to add “me toos” to bugs so MySQL developers could get prioritization FROM THE COMMUNITY for bugs in 5.1, which didn’t happen fast or good enough.
Perhaps you meant it as a good thing; in the context of the next sentence you seem to be saying that the neglected bug reports will stay neglected, which is most likely untrue, as they will be revisited and with more facts, details, and affected customers (paying and non-paying!), MySQL will be able to better fix the bugs.
The last sentence of the bullet points is clearly negative, and does not give any facts. Something that’s more factual: “I’m glad to see this tool come out, we do a lot of this work at Percona and have developed similar tools. Unfortunately we’ve found that we can debug the problem but in many cases we can’t fix it.”
So, yes, it’s negative. It’s criticism that’s not constructive — it’s *destructive* criticism. Perhaps that’s not the way it’s intended, but that’s the way it comes out. As a public face to the world for Percona, you might want to read things more carefully if you really don’t think this post is negative.
Percona is an amazing company, and I fully believe that the points you make under the negativity are valid. However, to say that this post is not negative is missing a big communication rift — it seems Percona doesn’t realize that posts like this piss MySQL employees off (like Jan Kneschke above).
Personally, I don’t care one way or the other. I agree with Baron that this is a promising tool and I’d like to see more. I haven’t looked into it so I can’t give any criticism, but if/when I do the criticism will be *constructive*.
Sheeri K. Cabral
11 Feb 09 at 3:35 am
Sheeri,
Thanks also for your thoughts. I appreciate them.
Xaprb
11 Feb 09 at 11:00 am
Peter answered some important questions here: http://blogs.mysql.com/peterg/2009/02/13/todo-mysql-performance-schema-7/
Xaprb
15 Feb 09 at 4:00 pm
I was searching around on the net for some public PERFORMANCE_SCHEMA worklogs, and found this post (must have missed it, ooops).
I’ll ignore the baits :D
We would have done the work and contributed it back to Oracle, though..
Seems to me it’s more likely that InnoDB will more tightly integrated now though eh?! :)
Mark Leith
1 May 09 at 5:04 am