Oracle Claims Dramatic MySQL Performance Improvements

New submitter simula67 writes "Oracle wins back some karma from the open source community by releasing MySQL cluster 7.2 with ambitious claims of 70x performance gains. The new release is GPL and claims to have processed over 1 billion queries per minute. Readers may remember the story about Oracle adding commercial extensions to MySQL."

PostgreSQL

[Anonymous Coward]

Shove it Oracle, I'll stick with PostgreSQL.

Considering sub queries in IN statements.

[micheas]

If you create a query in mysql with an IN statement in the where clause and you put a sub query as the in statement current versions will run the query once for each row of the primary table you are querying. Caching result alone would probably get the 70x speed up. I am suspect that there are other performance stupidities in mysql that are worked around by people doing a simple query and then using php/perl/python/java/etc to parse the result and generate the second query.

Re:Considering sub queries in IN statements.

[K. S. Kyosuke]

yes, but many database engines have problems with inner select statements. Refactor your query to use a join an you'll be fine.

And what's wrong with using an RDBMS with a non-braindead optimizer?

Re:Considering sub queries in IN statements.

[cheater512]

The poor RDBMS has to put up with crap like that over and over again.
It will probably need therapy after you are through with it.

The programmer is supposed to know how to use the tool effectively to get the best performance.
In that example there is a stupidly obvious solution - use a join.

Re:Considering sub queries in IN statements.

[Anonymous Coward]

"some" people are perfectly aware of JOIN and have suffered one too many hairball, incomprehensible SQL statements with 10+ tables mashed together under FROM using JOIN. Sub-queries provide opportunities to factor out some of these into discrete parts that can be individually examined and tested.

Please, stop discouraging the use and application of sub-queries. If you have encountered people that insist on using them despite MySQL's tragically bad optimizer, it is likely they have been exposed to powerful databases that haven't been copping out on basic RDBMS functionality for over a decade. Instead, harangue the MySQL developers; they are the people at fault.

Re:Considering sub queries in IN statements.

[K. S. Kyosuke]

The poor RDBMS has to put up with crap like that over and over again. It will probably need therapy after you are through with it.

The programmer is supposed to know how to use the tool effectively to get the best performance. In that example there is a stupidly obvious solution - use a join.

To me that sounds like fixing a bug in the wrong place. RDBMS is *not* supposed to be dumb. If it were supposed to be dumb, we would not be using SQL in the first place and we'd be passing our own execution plans in the DB engine's internal intermediate language instead. (Well, you can sort of do it with Firebird (BLR) and SQLite (VDBE), but it's not how it's supposed to be used.)