Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Databases Open Source Oracle Upgrades

Oracle Claims Dramatic MySQL Performance Improvements 168

Posted by timothy
from the breathing-in-those-sulfurous-fumes dept.
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."
This discussion has been archived. No new comments can be posted.

Oracle Claims Dramatic MySQL Performance Improvements

Comments Filter:
  • PostgreSQL (Score:0, Insightful)

    by Anonymous Coward on Thursday February 16, 2012 @02:04PM (#39063913)

    Shove it Oracle, I'll stick with PostgreSQL.

  • by micheas (231635) on Thursday February 16, 2012 @02:12PM (#39064007) Homepage Journal
    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.
  • by K. S. Kyosuke (729550) on Thursday February 16, 2012 @02:30PM (#39064299)

    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?

  • by cheater512 (783349) <nick@nickstallman.net> on Thursday February 16, 2012 @03:56PM (#39065575) Homepage

    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.

  • by Anonymous Coward on Thursday February 16, 2012 @04:09PM (#39065801)

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

  • by K. S. Kyosuke (729550) on Thursday February 16, 2012 @06:22PM (#39067561)

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

"Buy land. They've stopped making it." -- Mark Twain

Working...