Sun's Mickos Is OK With Monty's MySQL 5.1 Rant 155
narramissic writes "Back on November 29, MySQL developer Michael Widenius trashed Sun's decision to give MySQL 5.1 a 'generally available' designation in a now-infamous blog post. Widenius warned users to be 'very cautious about MySQL 5.1' because 'there are still many known and unknown fatal bugs in the new features that are still not addressed.' And now we get Sun's response. In an interview Monday, Marten Mickos, senior VP of Sun's database group, said, 'I learned over many years about the benefits and the painfulness of absolute transparency in open source. A little bit of debate never hurts. This is part of being an open-source company. ... People are free to blog about what they want.' Doubtless, this will do nothing to end the debate over whether Widenius will follow fellow MySQL co-founder David Axmark's lead and leave Sun."
Re:Debate? (Score:4, Informative)
Monty went beyond that to suggest that all the company talent was going toward other projects instead of MySQL and that was hurting the quality of the project. So it doesn't seem to be so much about where the quality bar is set and how the company is managed rather than over the existence of bugs. Some of it might be because there isn't a strong enough grasp of how the product is being used to allow for people to make those kinds of value decisions.
More importantly though it's impressive to see a company realize that instead of trying to squelch their development people, letting them say what they want and contribute to the conversation rather than telling them to shut up and get in line is rather impressive. The idea that open source means more than just disclosing code is a key part of becoming a member of the community and it seems like a culture shift in Sun's thinking. Definitely progressive from 5-10 years ago, when this would have been unthinkable.
Re:To their credit (Score:5, Informative)
Re:MySQL join performance deficiency, 2 orders of (Score:5, Informative)
You're probably not going to like this answer but....
The data is not in an optimal form for MySQL. Consider storing the IP address as a BINARY CHAR field, and not as a number. Order the bytes so that it is in big-endian byte order. Now MySQL can use it's indexes.
The problem is that MySQL treats index keys as a binary string so if you are using a function to join two tables, MySQL does things the hard way.
Re:MySQL join performance deficiency, 2 orders of (Score:2, Informative)
Re:MySQL join performance deficiency, 2 orders of (Score:5, Informative)
The problem with this scenario and why it will always bother people who are used to non-MySQL RDBMS, is that really, you haven't had to think about things like that in a decade (more if you were giving your first born to Oracle).
Equivalent where vs joins should give similar query plans. If not, since the SQL standard where JOINs are first class citizen state that its what you should use for linking tables (no matter how exotic the JOIN), it should handle that better, and having to force an index is usually a crutch (even Microsoft will often consider it a bug, and the logical scenarios get fixed between versions... in 2000 you had to force em every so often, in 2005 they solved most of them, in 2008 I haven't seen an occurance where the analyzer got it wrong...).
The lack of index in the address table is indeed fairly illogical here, but for such a simple query, most RDBMS will be able to do it fine anyway, -especially- with table statistics. In this case, my pragmatic self would never expect it to be fast, but in most RDBMS, it will still be zippy. The only ones I've personally tried that will choke (even with gigs of data) are MySQL and PervasiveSQL (Pervasive makes MySQL look like the holy grail, thats for sure). I've had douzens of databases with up to 50-100 gigs of data (though it was spread out over at least 75-100 tables, sometimes up to a thousand) with no indexes aside for the primary keys and the systems were fast, on MSSQL, Oracle and Postgres (not saying indexes wouldn't have helped a ton, but it wasn't my decision to take), so its a bit of a culture shock to many when you have to spell out your intent to the database that much.
Re:Debate? (Score:2, Informative)
Sun may be more "progressive" than some, but this statement from the article clearly reveals who's running the show:
"...There were still some outstanding critical bugs, and Marketing and Sales were pressing for a release," Maxia added.
This was "understandable," he said. "The economic situation of Sun was not good, the company had just cut 2,500 jobs, and we needed the new release to boost sales.
Seems to confirm the original complaint.
Re:To their credit (Score:5, Informative)
Sounds like you were using MyISAM. InnoDB will find and detect corrupt pages - and considering that pages get written into the doublewrite buffer, then written to the log, then written to the tablespace, it's fairly unlikely that things end up corrupt without some kind of disk-related issue.
It doesn't auto-repair table because there can be several issues that could cause that to be a bad idea - for example, a broken RAID controller or faulty disk. If your disk is losing writes sporadically (which I've seen happen), then you'll move from a few corrupt records to a swath of corrupt records.
Re: the date thing, the philosophy was that it's not the database's job to validate data. You could use -00-00 to refer to an all-year event in some kind of astronomical calendaring system, for example, or 0000-mm-dd to refer to something that happened 2008 years ago. If you really want to limit it to a specific range of dates, then you can tell MySQL that, and you can enforce it in your application (or in a trigger, for that matter).
Your rant would have been very apropos ten years ago; nowadays it sounds like you're just holding a grudge because you don't know how it works or what it does.
Re:Uhm (Score:3, Informative)
Re:MySQL join performance deficiency, 2 orders of (Score:2, Informative)
Having experience with this problem, I can tell you that the problem is that MySQL's implementation of b-tree indices doesn't work well for ranges (specifically, it can only eliminate rows on one side of the inequality). The solution is to use rtree indices (GIS functions, 'SPATIAL INDEX').
I didn't come up with the technique, but I can't find the webpage where I found it. I did end up using it for a geolocation system though.
Re:MySQL join performance deficiency, 2 orders of (Score:3, Informative)
The basic idea is that you create a polygon column and create an entry that corresponds to the start/end points for each row in your table, then you can run a query like this:
SELECT * FROM your_table WHERE MBRContains(polyfield, POINTFROMWKB(POINT(INET_ATON('1.2.3.4'), 0)));
As a point of reference, the above query runs in my local DB here in 0.02 seconds for any IP I can throw at it.
HTH.
Re:To their credit (Score:2, Informative)
MySQL has all the nice features any commercial enterprise level RDBMS has. The problem is that you can't use them together.
Re:Debate? (Score:2, Informative)
Seems to confirm the original complaint.
Please read carefully the next statement in the article.
After that phase, there were a lot of bug fixing before Community and Support agreed to a release. (or read the original article [sun.com])
G.M.