Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Sun's Mickos Is OK With Monty's MySQL 5.1 Rant

kdawson posted more than 5 years ago | from the say-what-you-want dept.

Databases 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."

cancel ×

155 comments

Sorry! There are no comments related to the filter you selected.

Uhm (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26042069)

Who? What? Does anybody care?

Re:Uhm (4, Insightful)

WillDraven (760005) | more than 5 years ago | (#26042127)

While I think the AC may be overstating this a bit, I do think the term 'infamous' is being a bit overused here. Ask any random person on the street about this issue and you're probably going to get a response along the lines of "What's MySQL?"

Re:Uhm (3, Interesting)

philspear (1142299) | more than 5 years ago | (#26042283)

So tell us, what exactly IS yourSQL?

Re:Uhm (4, Funny)

moderatorrater (1095745) | more than 5 years ago | (#26042461)

iSQL

50% more pretentious, runs all the coolest sites in the world.

Re:Uhm (3, Funny)

aliquis (678370) | more than 5 years ago | (#26042607)

If there really was an iSQL it would cost money, decide which SQL statements you wanted to run and how to run them, have no export to other databases but come in a really really flashy box.

Re:Uhm (3, Funny)

carlzum (832868) | more than 5 years ago | (#26042697)

Why yes, there is an iSQL [microsoft.com] , though it's a command-line client tool for MS SQL. But it does meet all of your criteria.

Re:Uhm (2, Informative)

LurkerXXX (667952) | more than 5 years ago | (#26043431)

Bzzzt. It exports to Oracle just fine by default, thanks for playing.

Re:Uhm (0)

Anonymous Coward | more than 5 years ago | (#26044559)

Nerds all over world would try to replicate it with gnuSQL, hack together only half the functions and when a user messaged them with a bug or feature request scream at them "Doesn't happen on my computer, its open source fix it yourself!"

Re:Uhm (2, Funny)

philspear (1142299) | more than 5 years ago | (#26042613)

Uh... I didn't know yourSQL was actually a thing, I was trying to make a joke.

Re:Uhm (1)

Kneo24 (688412) | more than 5 years ago | (#26042621)

So tell us, what exactly IS yourASL?

Fixed that for ya.

Re:Uhm (2, Funny)

Random Street Person (1427137) | more than 5 years ago | (#26042385)

What's MySQL?

Re:Uhm (1, Funny)

Anonymous Coward | more than 5 years ago | (#26042753)

What's MySQL?

A child Process!

Puns: Never explain, never apologize.

Re:Uhm (1)

jaxtherat (1165473) | more than 5 years ago | (#26042805)

Only if you pronounce it MySEQUEL.

Re:Uhm (1)

woot account (886113) | more than 5 years ago | (#26043271)

I was wondering why that joke didn't make any sense.

Re:Uhm (1)

jaxtherat (1165473) | more than 5 years ago | (#26043449)

Don't worry, it still doesn't. I'm just trying to rationalise the EPIC FAIL of a joke to stop my brain from exploding :)

Re:Uhm (5, Insightful)

Anonymous Coward | more than 5 years ago | (#26042437)

We use MySQL in a number of critical aspects of our company. I'd rather have a company be honest and let me know I might have some issues with this new release than pretend there are no issues. That lets me stay with my current version and upgrade later.

Rather be on the stable blunt edge in critical infrastructure, not the bleeding edge.

Re:Uhm (2, Interesting)

daeg (828071) | more than 5 years ago | (#26043149)

The problem is, MySQL hasn't had a stable, crash-free release in MANY years. The version you think is stable is only stable with your data set and queries.

Re:Uhm (0)

Anonymous Coward | more than 5 years ago | (#26044647)

We just use binary files in a number of critical aspects of our company, we don't need full data integrity, just pure speed.

Our homemade "database" is ten thousand times faster than MySQL's MyISAM db engine.

Re:Uhm (1)

sleeponthemic (1253494) | more than 5 years ago | (#26043951)

Ahh, but is that unacceptable use of "infamous"?. If "random on the street" is your gauge, very little could be labeled such. Personally, I think your analogy is overstating it, rather than the summary. Ask a person using Mysql for production code about this issue. That is the gauge of infamy in this particular case.

If they're unknown... (0)

Anonymous Coward | more than 5 years ago | (#26042119)

...then how do we know they are fatal?

Cue Donald Rumsfeld (2, Funny)

spiffmastercow (1001386) | more than 5 years ago | (#26042197)

prepare to hear about known unknowns

Re:Cue Donald Rumsfeld (1)

Pvt_Ryan (1102363) | more than 5 years ago | (#26044821)

yes, you must expect the unexpected grasshopper

turd post (-1)

Anonymous Coward | more than 5 years ago | (#26042121)

A couple weeks ago, while browsing around the library downtown, I had to take a piss. As I entered the john, Barack Obama -- the messiah himself -- came out of one of the booths. I stood at the urinal looking at him out of the corner of my eye as he washed his hands. He didn't once look at me. He was busy and in any case I was sure the secret service wouldn't even let me shake his hand.

As soon as he left I darted into the booth he'd vacated, hoping there might be a lingering smell of shit and even a seat still warm from his sturdy ass. I found not only the smell but the shit itself. He'd forgotten to flush. And what a treasure he had left behind. Three or four beautiful specimens floated in the bowl. It apparently had been a fairly dry, constipated shit, for all were fat, stiff, and ruggedly textured. The real prize was a great feast of turd -- a nine inch gastrointestinal triumph as thick as his cock -- or at least as I imagined it!

I knelt before the bowl, inhaling the rich brown fragrance and wondered if I should obey the impulse building up inside me. I'd always been a liberal democrat and had been on the Obama train since last year. Of course I'd had fantasies of meeting him, sucking his cock and balls, not to mention sucking his asshole clean, but I never imagined I would have the chance. Now, here I was, confronted with the most beautiful five-pound turd I'd ever feasted my eyes on, a sausage fit to star in any fantasy and one I knew to have been hatched from the asshole of Barack Obama, the chosen one.

Why not? I plucked it from the bowl, holding it with both hands to keep it from breaking. I lifted it to my nose. It smelled like rich, ripe limburger (horrid, but thrilling), yet had the consistency of cheddar. What is cheese anyway but milk turning to shit without the benefit of a digestive tract?

I gave it a lick and found that it tasted better then it smelled.

I hesitated no longer. I shoved the fucking thing as far into my mouth as I could get it and sucked on it like a big half nigger cock, beating my meat like a madman. I wanted to completely engulf it and bit off a large chunk, flooding my mouth with the intense, bittersweet flavor. To my delight I found that while the water in the bowl had chilled the outside of the turd, it was still warm inside. As I chewed I discovered that it was filled with hard little bits of something I soon identified as peanuts. He hadn't chewed them carefully and they'd passed through his body virtually unchanged. I ate it greedily, sending lump after peanutty lump sliding scratchily down my throat. My only regret was that Barack Obama wasn't there to see my loyalty and wash it down with his piss.

I soon reached a terrific climax. I caught my cum in the cupped palm of my hand and drank it down. Believe me, there is no more delightful combination of flavors than the hot sweetness of cum with the rich bitterness of shit. It's even better than listening to an Obama speech!

Afterwards I was sorry that I hadn't made it last longer. But then I realized that I still had a lot of fun in store for me. There was still a clutch of virile turds left in the bowl. I tenderly fished them out, rolled them into my handkerchief, and stashed them in my briefcase. In the week to come I found all kinds of ways to eat the shit without bolting it right down. Once eaten it's gone forever unless you want to filch it third hand out of your own asshole. Not an unreasonable recourse in moments of desperation or simple boredom.

I stored the turds in the refrigerator when I was not using them but within a week they were all gone. The last one I held in my mouth without chewing, letting it slowly dissolve. I had liquid shit trickling down my throat for nearly four hours. I must have had six orgasms in the process.

I often think of Barack Obama dropping solid gold out of his sweet, pink asshole every day, never knowing what joy it could, and at least once did, bring to a grateful democrat.

Re:turd post (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26042275)

you're a useless human who's better off dead. In any case, this "the producers" bit is old and done before. yawn

Re:turd post (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26042287)

"aristocrats"?

Re:turd post (0)

Anonymous Coward | more than 5 years ago | (#26044315)

It's spelled "aristocats". Yeah, for sure!

Thirsty for a frosty one (0, Funny)

Anonymous Coward | more than 5 years ago | (#26042279)

A while ago, while browsing Sun's downtown website, and had to take the piss. As the java plugin loaded, I

Transparency (1, Funny)

webword (82711) | more than 5 years ago | (#26042327)

If code's too transparent you see right through it to the bloody programmers and their coffee and Monster drinks. In fact, you might see into their dark hearts. You'll see little Guitar Heroes and Battlestar Gallacta action figures. Maybe even, gasp!, some Natalie!

Transparency? Shudder!

Debate? (4, Insightful)

FranTaylor (164577) | more than 5 years ago | (#26042435)

What is the debate? MySQL releases with known crashing bugs. Noone is disputing that.

Is the debate over whether or not it is okay to ship a database with known crashing bugs?

It really surprises me to hear someone from Sun saying that one can debate the merits of a crashing database. If this is the expected level of performance from MySQL, no wonder people shun it. At the very least they could have called it a beta or rc release, that would set the expectation level at something approaching reality.

To their credit (4, Insightful)

coryking (104614) | more than 5 years ago | (#26042595)

MySQL has never been a stable database program. I've never had any other database system that just blows a database table at random. Nothing is more exciting then having a website go down because one of the tables got marked "corrupt" and you have to go "REPAIR TABLE". The damn thing might not even have a load on it and it will blow up!

First of all, what is MySQL doing that corrupts tables during normal operation and second of all? Seriously, a database shouldn't crash like that, ever.

Second of all, it might as well try to auto-repair the damn table. I mean, I've never had it loose data, only somehow decide the table was "corrupt" and then taken offline. And who cares if you do it automatically and it looses data, this is MySQL we are talking about here! They make no claim about data integrity and the user base doesn't even know what that means (must be a car or some "enterprise" feature used only by NASA and Fortune 50 companies)! I mean, 0000-00-00 is a valid date according to them!

But alas, this is MySQL we are talking about here. I mean, it isn't like you are putting any sensitive data on it right? I mean, surely only a fool would use it for anything besides storing data like "number of shoes in my closet" or "number of purses owned by the wife", right?

Good 'ol MySQL. I mean, what fun is a database server that is consistent or predictable?

Re:To their credit (1)

larry bagina (561269) | more than 5 years ago | (#26042639)

I don't know what it's doing, but I know what it's not doing: ACID.

Re:To their credit (4, Informative)

carlzum (832868) | more than 5 years ago | (#26042749)

If you consider InnoDB [wikipedia.org] part of MySQL, then it has supported ACID compliant transactions for a while now.

Nice (3, Insightful)

coryking (104614) | more than 5 years ago | (#26042849)

But what happens if you want to do full text search? Besides, your nice ACID InnoDB kinda backfires when half the tables are using MyISAM, doesn't it? And good thing MySQL lets you know when your nice happy transaction will not roll back properly because half the tables are MyISAM, right?

As I said, what fun is a database server that is consistent or predictable?

innodb != fast (2, Interesting)

Anonymous Coward | more than 5 years ago | (#26043127)

Sure, innoDB gives you transactions, but at the cost of a lot of MySQL's vaunted speed; half of the reason it took so much of the early open source DB business, lo those many years ago (the other being ease of app development.)

I'm a database rube, but even I've left MySQL for PostgreSQL. Try PostgreSQL, just try it. This isn't your old 7.3 postgres anymore, no siree. ACID all the way, kicks InnoDB's butt and is probably faster than MyISAM most of the time for most of your stuff.

8.4 is nearing completion and it's going to be fabulous. Try it.

Re:innodb != fast (1)

carlzum (832868) | more than 5 years ago | (#26043345)

I'm not defending MySQL's performance or stability, I just wanted to point out that with InnoDB it's ACID compliant. I use Oracle and postgreSQL for all of my "enterprise" applications, though mostly because PL/SQL ports to postgreSQL pretty well. We've been on 8.0 for a few years now and I'm very happy with it. The only use I have for Oracle now is the data warehouse (tied to Oracle Warehouse Builder) and Oracle applications (Financials, third party apps).

Re:To their credit (2, Informative)

fatp (1171151) | more than 5 years ago | (#26044079)

But InnoDB is very slow. This contradicts with the claim that MySQL is fast.

MySQL has all the nice features any commercial enterprise level RDBMS has. The problem is that you can't use them together.

Re:To their credit (0)

Anonymous Coward | more than 5 years ago | (#26044163)

So long as your query is MySQL transaction compatible. You cannot for example create/drop/alter a table in a transaction. I don't understand why they can get away with claiming ACID compliance when only a subset of possible queries can be done in a transaction. Of course PostgreSQL makes no distinction, everything except maybe CREATE DATABASE can be done in a transaction from my experience.

Re:To their credit (1)

LCValentine (982220) | more than 5 years ago | (#26042733)

Loose data are hot... just like slots.

crashing database == lost data (2, Insightful)

FranTaylor (164577) | more than 5 years ago | (#26042767)

If your database is crashed and is no longer capable of accepting data, how is that different from losing data? Go ahead and explain that with a straight face. Do they have another data store where you can keep your data until the database is fixed?

Sun should be ashamed of themselves for even calling this abomination a database in the first place. The word 'database' carries a whole host of expectations that the product simply does not live up to. A text file makes a better database than MySQL.

We are in a post-rational debate (2, Insightful)

coryking (104614) | more than 5 years ago | (#26042837)

If your database is crashed and is no longer capable of accepting data, how is that different from losing data?

I mean this is mysql here, not a real relational database. Kind of like sloppy cowboy VB coders of yore, MySQL has the same kind of attitude. "If it works, who cares if it is right".

I mean, sure people site "Well, Slashdot, FaceBook, and BIGCO use it, so MySQL is okay". But have those people ever realized how easy it is to lock yourself into MySQL? MySQL is so full of non-standard behavior and gotchas that it can be very painful and difficult to migrate to a real database. So what to companies do? Layer on a huge pile of Memcached and crazy "archive databases" to scale when if they had started with a more standard, scalable database system maybe they could have allocated their developer time to something more productive.

Anyway, I rant. I just think MySQL is only used by large companies because either they don't understand how much extra developer hours are spent working around MySQLisms or they know MySQL sucks, but know that it is to costly to migrate to something better.

But that has nothing to do with your post or my original post does it? I'll conclude with the main problem--Like VB, MySQL grew a whole crop of developers who dont know any better. While I dont know if you can blame that on the database or a programming language, I chuckle when I see MySQLisms in code (like never using a "JOIN" because it mysql is "faster if you give it small SELECT statements).

/Rant Off

Re:crashing database == lost data (4, Insightful)

multipartmixed (163409) | more than 5 years ago | (#26043139)

> If your database is crashed and is no longer capable of accepting data, how is that
> different from losing data? Go ahead and explain that with a straight face.

Well, for example, losing bank deposits is a lot worse than not accepting them because the database is down. This illustrates why in database land it's important to never lose data, and to always know that the contents of your database is correct.

Or, to explain in more detail...

There are known knowns.
There are things we know we know.
We also know
There are known unknowns.
That is to say
We know there are some things
We do not know.
But there are also unknown unknowns,
The ones we don't know
We don't know.

And the unknown unknowns are most dangerous when it comes to RDBMS integrity.

Re:crashing database == lost data (1)

wik (10258) | more than 5 years ago | (#26043495)

Good to see Rumsfeld invoked to explain databases. It really warms my heart.

If only he had remembered the unknown knowns--the data your DBMS just lost--the set would be complete.

Actually, you're wrong. (1)

kbrasee (1379057) | more than 5 years ago | (#26043293)

A text file makes a better database than MySQL.

A text file does not make a better database than MySQL. No queries. No transactions. No way.

Re:Actually, you're wrong. (1)

Shados (741919) | more than 5 years ago | (#26044067)

You most definately can run queries on text files, as various implementations allow it (for example, there's an oledb provider that can do it, some ODBC interfaces, etc). And if you're creative, you could use some distributed transaction system to fake transactions (though I'll admit thats pushing it). Then again, for a large part of its life, MySQL didn't have transactions, no? Good thing they fixed that.

Re:To their credit (0, Flamebait)

dkleinsc (563838) | more than 5 years ago | (#26042823)

The problem, in my opinion, is that a lot of folks have become convinced that MySql is an absolutely essential part of a web application that runs on Linux and Apache. It's getting used largely because it's part of the LAMP stack that some boss has heard a few things about.

Having used both MySql and several real databases (postgres, Oracle, even MS SqlServer) throughout my career, I have yet to figure out what MySql's appeal really is. It's like the PHP of databases: it was one of the first to enter the game of open database options, and so a lot of people use it despite causing lots of grief.

Re:To their credit (2, Interesting)

domatic (1128127) | more than 5 years ago | (#26043247)

MySQL has never been a stable database program. I've never had any other database system that just blows a database table at random.

I see you've never tangled with FileMaker Pro.

Re:To their credit (4, Interesting)

QuietLagoon (813062) | more than 5 years ago | (#26043249)

MySQL has never been a stable database program.

. (5 insightful???) Well thats kind of harsh.

I've run MySQL datase servers on my websites for nearly 10 years without one problem. Tens of thousands of hits per day. No problems. MySQL is always there, and always working.

I only can wish that my desktop Windows were one-hundreth as reliable.

Re:To their credit (0)

Anonymous Coward | more than 5 years ago | (#26045113)

I've run MySQL datase servers on my websites for nearly 10 years without one problem.

That's an anecdote, not data. Just because YOU didn't happen to run into bugs in YOUR particular application and with YOUR particular workload on YOUR particular iron doesn't mean they don't exist.

Re:To their credit (5, Informative)

Sentry21 (8183) | more than 5 years ago | (#26043291)

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:To their credit (1, Insightful)

trawg (308495) | more than 5 years ago | (#26043337)

Why do I never have mod points whenever MySQL threads come up?! good post.

Re:To their credit (2, Insightful)

larry bagina (561269) | more than 5 years ago | (#26043401)

There is no year 0.

Re:To their credit (2, Insightful)

ortholattice (175065) | more than 5 years ago | (#26044831)

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.

Wow, I am speechless. This is one of the best attempts to turn a bug into a feature I've seen in years! You should work for MySQL's marketing department. Now I'm really excited to hear about the creative things one can do with Feb. 31st...

Re:To their credit (3, Insightful)

wytcld (179112) | more than 5 years ago | (#26043361)

Must be in YMMV territory here. I've been running MySQL behind production Web servers for years, through many iterations of MySQL. I've not once had it "blow a table." No doubt that's been your experience. But I have to wonder if it was MySQL that was the weak point in your configuration.

I've found, and reported, bugs in years past. Those were all in peripheral capabilities though, not in basic data handling. MySQL was always good about addressing them. Haven't hit any since Sun took over.

Re:To their credit (2, Interesting)

Jellybob (597204) | more than 5 years ago | (#26045025)

I think people are blowing this out of proportion, but in 5 years of using MySQL, I've seen it happen twice.

Once was on a personal site I didn't really care about, the other time was on a site getting tens of thousands of requests an hour. As other people have said, there really is no excuse for dying like that.

Re:To their credit (3, Interesting)

StuartHankins (1020819) | more than 5 years ago | (#26043743)

I'm not having any troubles, and I populate several million records each day spread across approx 100 tables without error. I've done this for several years.

I happen to be in a situation where the host system isn't ODBC-compliant so we hosted MySQL on the same box and use custom code to get data out of it. Then I import from MySQL into MS SQL Server. It's very quick for what I do and I haven't had to spend time on maintenance and tuning really like I do MS SQL Server. No table partitioning yet, no manual placement of indexes on separate filegroups etc. Oh, and no data loss. And while it's importing / exporting the MySQL load on the server is minimal -- I'm accustomed to seeing it 90%+ idle at that time of the morning.

Granted, I use a small portion of its features, but even things like the ability to load data and have it either replace or append as needed saves another pass per table. With my tiny maintenance window this really helps.

YMMV though. Maybe because I stay a version behind bleeding edge (5.0/5.1) it helps?

Re:To their credit (1)

fibrewire (1132953) | more than 5 years ago | (#26043893)

Clearly "coryking" was making a reference to the reliability of how awesome MySQL really is, and how ridiculous it is to have a company like Sun try to say "If it breaks, then we fix it" to the FOSS community. Its exactly that kind of thinking that put FOSS where it is today.

For example, imagine that Microsoft and Sun are GM and Ford 20 years ago, and that FOSS is Honda. Everybody points and laughs at the little box that could, what a great idea - but people don't want reliability, they want features. But now because unforseen turns in the economy, an informed general public, and Honda's ability to place Marketing ***BEHIND*** the Scientific Method, GM and Ford are left scratching their head, wondering what happened to their plan to rape consumers. And now the great American motor companies need a few hundred billon dollars of OUR friggin money to pay for their mistakes, while Honda is now the gold standard. Are we to make the same mistake with FOSS?

Now put the CEO's of GM behind the wheel of Honda. You expect the Honda engineers to WHAT? Screw the consumers and make the model year release date! WHAT!

If only Hondas were free... a guy can dream...

Re:To their credit (2, Insightful)

blind biker (1066130) | more than 5 years ago | (#26044673)

I have been criticizing MySQL for years, because of what I perceived as awful stability. I would be the last one to defend them.

That said, MySQL has never ever crashed for me. Not once. But my usage scenario is one of very light load. That seems still more traffic than "The damn thing might not even have a load on it and it will blow up!", so, maybe (please don't get mad, just an idea, OK?) there is a chance that your configuration is in some way contributing to this?

Re:Debate? (3, Informative)

ruin20 (1242396) | more than 5 years ago | (#26042653)

From what I could tell the debate was over how serious the bugs were and how they should or shouldn't be allowed into something that is an official release.

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.

What terrible expectations! (1)

FranTaylor (164577) | more than 5 years ago | (#26042821)

It's impressive that a company ships junk and admits it? Since when is that impressive? Boy are you setting the bar low.

Re:Debate? (2, Informative)

iminplaya (723125) | more than 5 years ago | (#26043091)

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:Debate? (2, Informative)

datacharmer (1137495) | more than 5 years ago | (#26044665)

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.

Re:Debate? (1)

sleeponthemic (1253494) | more than 5 years ago | (#26042699)

Is this unacceptable? Maybe, maybe not. Surely people rarely rely on latest versions of DBs for production code. I'm not in the DB biz any more (and I wasn't really heavily into it when I was) but it seems to me you can't afford to be taking risks, using the latest versions.

Re:Debate? (1)

Z00L00K (682162) | more than 5 years ago | (#26044109)

It's not debating about a crashing database, but allowing a voice to be heard and not silenced.

There are certainly problems, but there will always be yet another bug no matter how hard you try. And let them be open about it.

If you like ignorance - stick with closed vendors like Microsoft.

What may be debated is if it was pushed into GA too early, and maybe it was. But don't shoot any messengers about that. The real benefits from this is that developers will know more about the issues and can work to solve them or circumvent them.

MySQL join performance deficiency, 2 orders of mag (5, Interesting)

nluv4hs (1422261) | more than 5 years ago | (#26042481)

My subject line sounds inflammatory yet see below for hard numbers and a simple, real example. Someone please show me how to coax MySQL to perform as well as PostgreSQL for this simple query (Postgres 496 times faster). It's been over two months since I posted this problem on two very [mysql.com] public forums [mysqlperformanceblog.com] , with no response from the MySQL community. Would someone please stand up for MySQL and save it from looking weak here?!

Re:MySQL join performance deficiency, 2 orders of (3, Interesting)

uss_valiant (760602) | more than 5 years ago | (#26042677)

I'm not really touching this potato, maybe you're running into some quirks / unfortunate query. Just some quick questions:
- Why don't you have a PK / any index in the address table?
- Did you try a different syntax (e.g. WHERE vs. JOIN ON)?
- Did you try setting different indexes? Tried forcing a specific index?

Re:MySQL join performance deficiency, 2 orders of (2, Informative)

nluv4hs (1422261) | more than 5 years ago | (#26042987)

Thank you for these thoughtful questions.
  1. The example setup [mysql.com] is intended as a minimal demonstration, so I left out any keys on address.
  2. I played a lot with where clauses, with no benefit. Anyway, shouldn't an industrial-strength RDBMS be able to interpret and optimize the simplest possible range join written as such?
  3. I configured the strongest possible indices on range: 2 unique, 1 non-unique. Yes I tried FORCE INDEX [mysql.com] , it made no difference (in execution time or EXPLAIN [mysql.com] output).

Re:MySQL join performance deficiency, 2 orders of (4, Informative)

Shados (741919) | more than 5 years ago | (#26043077)

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:MySQL join performance deficiency, 2 orders of (0)

Anonymous Coward | more than 5 years ago | (#26043479)

the address table is ~2000 rows, ~10 bytes per row. Unless it has a clustered index (google tells me Innodb uses clustered indexes, MyIsam doesn't) the index should be ignored in favor of in memory sorting.Storing the data in separate xml files, loading, parsing, and writing code to do the joining is probably faster than mysql.

Re:MySQL join performance deficiency, 2 orders of (1)

Shados (741919) | more than 5 years ago | (#26044037)

the address table is ~2000 rows, ~10 bytes per row. Unless it has a clustered index (google tells me Innodb uses clustered indexes, MyIsam doesn't) the index should be ignored in favor of in memory sorting.Storing the data in separate xml files, loading, parsing, and writing code to do the joining is probably faster than mysql.

I take it you're nluv4hs? In that case, if its only 2000 rows, this whole thing should be instant even without index indeed (on an average RDBMS), so this is quite the funny situation (though I'm not surprised).

Re:MySQL join performance deficiency, 2 orders of (1)

nluv4hs (1422261) | more than 5 years ago | (#26044085)

No GP wasn't me. MySQL 5.0.45 takes 10 mins 45 seconds on 2124 rows [mysql.com] (vs. 0 mins 1.3 seconds for PostgreSQL 8.1.11). Slow enough? Also GP misstated: an int(10) unsigned isn't 10 bytes wide, it's 4 bytes wide.

Re:MySQL join performance deficiency, 2 orders of (1)

Shados (741919) | more than 5 years ago | (#26044133)

Ahh ok, my mistake. 10 mins and 45 seconds on 2124 rows? Wow... ok, I take my back previous comments stating PervasiveSQL was worse. I had similar queries (with a few orders of magnitude more rows) on there and I was bitching that it took over 2 minutes, thinking it was insane.

10 minutes and 45 seconds? What is that thing doing? Loading Crysis as part of the query analysis process?

Re:MySQL join performance deficiency, 2 orders of (1)

nluv4hs (1422261) | more than 5 years ago | (#26044165)

The whole thing:
select range.id_country from address join range on address.address between range.begin_num and range.end_num

Re:MySQL join performance deficiency, 2 orders of (1)

Shados (741919) | more than 5 years ago | (#26044233)

Yeah, I've seen it... I was mostly just joking. Its such a simple query. I noticed one of the other poster showed a query that actually worked with some changes, but it was far from being a standard query, thats for sure.

Re:MySQL join performance deficiency, 2 orders of (-1, Flamebait)

LingNoi (1066278) | more than 5 years ago | (#26042865)

I can also make a query which makes MySQL look better the PostgreSQL. What's your point?

Re:MySQL join performance deficiency, 2 orders of (2, Interesting)

JambisJubilee (784493) | more than 5 years ago | (#26043075)

I can also make a query which makes MySQL look better the PostgreSQL. What's your point?

Okay... so what's your query?

Re:MySQL join performance deficiency, 2 orders of (0)

Anonymous Coward | more than 5 years ago | (#26043087)

please do.

Re:MySQL join performance deficiency, 2 orders of (0)

Anonymous Coward | more than 5 years ago | (#26044699)

I would love to see that query!

And please post something more advanced than 10000 inserts

Re:MySQL join performance deficiency, 2 orders of (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26045323)

LingNoi: I can also make a query which makes MySQL look better the PostgreSQL.

Slashdot: Put up or shut up

LingNoi: (shuts up)

Score: MySQL apologists 0, Postgres n+1.

Re:MySQL join performance deficiency, 2 orders of (4, Informative)

Antony T Curtis (89990) | more than 5 years ago | (#26042957)

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 (2)

nluv4hs (1422261) | more than 5 years ago | (#26043837)

Thank you for this interesting suggestion. I want it to work but I tried what you suggest and I don't see any difference in MySQL's query plan. I created exactly the same tables, except all columns of type int(10) unsigned converted to binary(4). The query plan is identical to the original [mysql.com] .

Re:MySQL join performance deficiency, 2 orders of (1)

kestasjk (933987) | more than 5 years ago | (#26044569)

That's silly; IPs are 32 bit numbers, and MySQL has functions INET_NTOA and INET_ATON specifically to allow IPs to be easily stored as integers.

Looking at his query I'm not really sure what he's trying to do, but it's a full join without join clause or an index on one of the tables which throws up a few red flags. Whatever the guy was trying to do can probably be done in a much better way.

If MySQL can't do inefficient queries efficiently I don't care. It does efficient queries like the ones that run my site (and this one, and google) quick enough.

Not a fanboy, can't comment on 5.1, but "someone optimize my query" isn't a good database criticism.

Re:MySQL join performance deficiency, 2 orders of (2, Informative)

tabrisnet (722816) | more than 5 years ago | (#26043671)

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 (2, Informative)

James_G (71902) | more than 5 years ago | (#26043807)

I'd suggest looking into the polygon type. This [mysql.com] article may be of some use.

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.

there's other SQL database programs... (1)

amclay (1356377) | more than 5 years ago | (#26042489)

I like postgreSQL, though mySQL is certainly very nice.

Re:there's other SQL database programs... (0, Redundant)

danbeck (5706) | more than 5 years ago | (#26042603)

I like postgreSQL, though mySQL is certainly very nice.

juST becAUSE postgreSQL hAS fuNNY cAPS doeSN't meAN evERY thING elSE usES iT tOO.

Re:there's other SQL database programs... (1)

amclay (1356377) | more than 5 years ago | (#26042727)

ha ha ha. courtesy laugh? it's "MySQL and PostgreSQL" I just didn't capitalize the first letter.

Sellouts (0)

Anonymous Coward | more than 5 years ago | (#26042561)

and this is exactly what can happen when you sellout (your soul) to <large failing company> *

* read: Sun, Microsoft, Oracle, EA, etc.

Re:Sellouts (1)

jadavis (473492) | more than 5 years ago | (#26043765)

You're way off base. Here's what Monty said:

I would like to point out that the current release is not something that can be said to be fault of Sun. The decisions to do a GA release was solely been made by the MySQL management in Sun. The only thing Sun can be blamed of is to not start fixing the MySQL development organization soon enough to ensure that things like this can't happen.

What should Sun have done to make this release better? By the time Sun purchased MySQL, it was already way behind the release schedule, and had serious problems. Should they have delayed it further and made it a 5-year gap between GA releases?

Also, releasing with known bugs is a known problem for MySQL anyway. The only reason it's news now is because:
  * They took 3 years to do a release, over a year in RC phase, and it's still got major problems.
  * People can't believe that MySQL still hasn't stabilized their product.

Donald Rumsfeld (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#26042587)

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.'

Donald Rumsfeld taken up blogging about MySQL now has he? That's quite a jump from the Department of Rag-head Bombing.

Same old, same old (1, Interesting)

Anonymous Coward | more than 5 years ago | (#26042751)

Sun buying MySQL is no different than Microsoft buying FoxSoft. Fox Software created Foxpro, a dBase-like database system. Not a true database, but something you could put a lot of data into. Fox Software sold Foxpro to Microsoft. Microsoft already had (has) MSSQL. First release after Microsoft got their hands on it: it could only store 1/500 as much data as before, and suddenly it got slower. It isn't completely dead yet, but no development has been done in 14 years. So its exactly like Sun and MySQL -- Sun bought MySQL to kill it.

Re:Same old, same old (4, Insightful)

/dev/trash (182850) | more than 5 years ago | (#26043035)

Except that mySQL is open Source, how can they kill the copy that I have on my hard drive and can re-distribute?

You're a genius (1)

multipartmixed (163409) | more than 5 years ago | (#26043157)

Finally, somebody who can explain when the MySQL binary package installer is broken on a bone-stock Solaris 10 sparc machine.

And, yes, it's totally broken, and yes, I reported it... last year. It simply does not, and CANNOT work unless you chmod a directory in /var/tmp from another window halfway through running.

My God People.

Re:You're a genius (1)

g1zmo (315166) | more than 5 years ago | (#26043213)

I've never had a problem installing MySQL from the installation CD/DVD on Solaris 10.

Re:Same old, same old (1)

KingMotley (944240) | more than 5 years ago | (#26043803)

Foxpro was more along the lines of Access, and it was specifically bought for one of the query features it had. The next Access release had incorporated that technology, and quite honestly was a much better GUI system than foxpro ever was. Foxpro was never a scalable solution, and suffered the same problems access did.

Jimmy Two Times (1)

iminplaya (723125) | more than 5 years ago | (#26042851)

"...And the bugs got fixed and then we moved on. We moved on."

Does anyone ever wonder what.... (2, Interesting)

QuietLagoon (813062) | more than 5 years ago | (#26043223)

... the Microsoft developers would say if they were allowed to?

.
Does anyone remember those Windows 2000 source code comments that leaked a few years back?

We should not punish Open Source for being Open Source. We are a community. OK, more like a family at Thanksgiving, bickering and such.

Re:Does anyone ever wonder what.... (2, Insightful)

jadavis (473492) | more than 5 years ago | (#26043767)

We should not punish Open Source for being Open Source.

But we should criticize it when they unleash bugs onto an unsuspecting public by mislabeling it "GA".

Giving away GPL rights... (1)

GNUPublicLicense (1242094) | more than 5 years ago | (#26044781)

What I really don't understand with Sun is why they would not want to "play by the rules" by forcing the contributors to give them their GPL rights... If they were a fondation like the FSF, right, no pb... but since they are a big company with not a such good reputation, it would be more reassuring to let the contributors keep their rights, like the Linux spirit and near 100% of the other GPL projects.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?