I was working on a client’s server today to troubleshoot some variances between the result timing of some queries. Guess what I came across – the profiler is not available in certain enterprise releases but it is available on community versions of the same release number.
I can understand if that feature was something that wasn’t fully tested in the enterprise code base and thus was only released in the community version – but if that’s the case then I don’t understand why the same version releases of Community and Enterprise can have different feature sets. That goes against the whole idea of versioning. Someone correct me if I’m wrong here but that is very frustrating.
Social tagging: enterprise > query tuning > troubleshooting
Yes it is confusing, and thus frustrating.
And it breaks the /*!50067 somekeyword */ logic as that relies on the (now no longer true) fact that a higher version always incorporates everything a lower version has.
If OurDelta ever does an Enterprise build of 5.0 (undecided), it’s likely to first rejig the source to include SHOW PROFILES.
Official releases of Enterprise binaries have only even version numbers and and official Community binaries have only odd numbers In 5.0 you should have no Communtiy binaries with the same version as Enterprise. Under the first few GA releases of 5.1 the version numbers will coincide however, the profiler is available in both Community and Enterprise releases if 5.1. I’d be curious to see the actual @@version strings from these servers that you say are of the same version but is Community and Enterprise.
Yep, you’re quite right. Currently profiling is not available in any Enterprise release, not just missing from some. That means e.g. 5.0.45 has partitioning, while 5.0.70 does not.
One of the dumbest decisions made in a totally dumb 5.0 release cycle.
Regards,
Jeremy
@Matthew Montgomery:
Here’s a great example: 5.0.68-enterprise does not have profiling. 5.0.67-community does have profiling. While they are not the same version it seems incredibly bizarre that a lower community version release would have features (that are very useful and I’ve never run into a bug with) that the higher release of enterprise doesn’t have. Basically, one more reason that enterprise isn’t getting my money -> either include it with both or don’t include it with either.
This is clearly called out on MySQL’s website:
“Important
Please note that the SHOW PROFILE and SHOW PROFILES functionality is part of the MySQL 5.0 Community Server only.
”
[Admin note: this is OBVIOUS, and I've read the manual plenty of times - but that's not what this blog post is about in the first place.]
I (MySQL Support Engineer) agree, it’s a pain in the butt. From all the 5.0 things that went wrong, that’s IMHO the biggest: the version mangling.. (my personal opinion BTW)
It’s awesome that the people that advocated to have functionality pushed in to the Community only versions and not Enterprise, are now the ones that are saying that it’s all broken when we actually did that (http://jcole.us/blog/archives/2007/08/09/mysql-community-split-officially-a-failure/).
“Currently profiling is not available in any Enterprise release, not just missing from some.”
There *is* an Enterprise version available with profiling enabled – 5.1.30 GA – now it has been vetted by the community.. As was originally stated.. As was originally advocated by the author..
Confused? I am. Not because of the way we handled this, though..
“That means e.g. 5.0.45 has partitioning, while 5.0.70 does not.”
Oh I’m sure you didn’t mean partitioning there..
Arjen – doing an Enterprise build that is not based solely on the Enterprise source, is hardly doing an “Enterprise Build”, I’m not sure why you’d bother, rather than just sticking with the normal OurDelta builds with all of their enhancements anyway.. Not saying “don’t do it”, that’s of course up to you, but it certainly wouldn’t be “Enterprise” if you modify it, and you’re already modifying the other builds anyway..
“I can understand if that feature was something that wasn’t fully tested in the enterprise code base and thus was only released in the community version”
That’s *exactly* what happened, though. MySQL 5.0 went GA with 5.0.18. SHOW PROFILES and SHOW PROFILE were added in MySQL 5.0.37. The policy is to not add new features in to Enterprise GA releases (we were most certainly GA at 5.0.37), and only to include them in the *next* major GA release should they be acceptable.
Why oh why do people advocate this, and then complain in the one instance that we actually did this?
OK, I didn’t advocate it and I am complaining. I have lots of Python that had to work over multiple MySQL versions. I am willing to add ‘if version > 5.0.30 then do this’. I don’t want to do anything else. If I can’t assume that a higher version # implies more features, then I don’t want to support that code. The solution is easy for me. I don’t want to use the Enterprise releases.
@ Mark: So, what if the solution were “no new features in any GA version, only in current development (Alpha) versions, for both Community and Enterprise”?
That’s basically the only way this is ever going to work.. I know you didn’t advocate it, I’d like to know your opinion on what you would like to see with regards to new features in Community and Enterprise GA releases however (i.e when/where they should be pushed etc.)..
I want one source tree. MySQL adds a lot of value for Enterprise customers to that source tree by distributing tested builds. I think that hiding the source for Enterprise subtracts value as several of us in the community rant about this.
MySQL should reduce the release time between major versions or add some (not major ones like RBR) features after the initial release of a version.
I expect that the Enterprise builds get additional features beyond what is in the one source tree as MySQL adds value via Enterprise only features, but I hope these are done via plugin interfaces.
@Mark Leith & Callaghan
I second the desire for one source tree. However, instead of plugins for Enterprise I would like to see the same features for both Community and Enterprise releases – the benefit of Enterprise being that you get support and the extra features like Query Analyzer and Enterprise Dashboard. I don’t understand any previously mentioned reasons to separate the releases into two trees – it only complicates the feature set and frustrates the users. There are community users that buy enterprise for certain servers and certain clients but do not forget that MySQL’s entire user base was built on the community – separating the features doesn’t do anyone any favors – even the paying customers.
Well, I have to say that you both are spot on with my own *personal* opinion.
I too would like to see smaller “features” (though perhaps not features, just extra usability enhancements – extra SHOW STATUS variables, perhaps new variables that do not alter behavior by default but do when enabled, etc.) – as long as they are not considered destabilizing.
I’ve tried to do this myself (innodb_stats_on_metadata, innodb_adaptive_hash_index, logging access denied messages to the error log, FLUSH TIMEZONES, to name a few), and I feel your frustration. innodb_adaptive_hash_index made it in to 5.0 – but that was only because of Bug#20358.
We’re currently working from a single source tree for 5.1 GA is at least, and I’m part of a team within MySQL/Sun that is trying to make the project more contributor friendly with regards to these small additions – from both the community *and* internally, because Support and others, as I mentioned, also see the same frustration as you guys on the outside. Hopefully we all should start to see changes in this area in the new year.
There’s a lot of work going on to bring release timelines down as well, and maybe further interim releases on the table too (i.e between 5.1 and 6.0).
In hindsight, we should probably have called 5.1 “6.0″, and we should have allowed smaller features like SHOW PROFILE in to a 5.1 taken directly from the “current” 5.0 version, and other incremental new “smaller” features afterwards in to 5.2, 5.3, 5.4, 5.6, etc. as they came of age. This may happen from 5.1 now though.
I’m an advocate of differentiation *around* the server as well, for the record.
Stick with us guys, we *are* listening, and there’s a whole bunch of us trying to change things for the better, with the blessing of people all the way “at the top”.