Personal Opinion: Half-baked = false analogy
Occasionally I hear the worry that MySQL might plan a feature that’s “half baked”. The term’s users include some of the world’s top MySQL experts so I’ll avoid a technical argument.
“In future we should not release a version with half-baked features and call it enterprise-ready.”
– Konstantin Osipov
http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/
“will Falcon be pushed hard as Innodb replacement even if it is half baked?”
– Peter Zaitsev
http://www.mysqlperformanceblog.com/page/2/?s=falcon&search_posts=true
As for me, though, I believe in features that others call “half baked”. I just don’t use the term much myself because it seems to convey a wistful regret. While “we’re halfway there” would generally be taken as a report of good progress.
The analogy seems to be with a cake: if you take a cake out of the oven and let it cool, and then find it’s not done, and then put it back in the oven to bake again, it won’t be good. But I prefer to analogize with a journey: if you take one step then you have completed a useful fraction of it. Of course, that assumes that the step is in the right direction, which means you must decide in advance what your destination is, and it is that — the failure to decide the destination — that causes embarrassing steps in seemingly random directions. I call those “drunkard’s walk” features, rather than “half baked” features. A bad sign is if someone at MySQL says “let’s do this because it’s low hanging fruit”, but I’m happy to say that I’m hearing those dread words less frequently nowadays.
So when I hear about a “half baked MySQL feature”, I’d want proof, not that this is only part of a job, but that it’s not getting us toward the job we really want.
May 19th, 2008 at 5:22 pm
Heh, you have a good point about the linguistic difference between “drunkard’s walk” and “half baked”…
Here is the proof you ask for:
MySQL stored routines: the compile cache is on the connection thread, not in a global cache, so stored procedures are re-compiled on each connection thread, which is a waste of resources (even if such connection-caches reduce global lock contention).
AFAIU, this design was chosen because it was considered too much of an overhaul to actually re-architect the pieces of the server kernel/runtime which would be necessary to implement a global compile cache, and thus we have a “half-baked” feature that although it works, isn’t efficient and causes perhaps more problems than it solves.
-jay