IBM's Power6 spotted bashing Oracle at 4.7GHz
The first public indication of IBM's Power6 muscle has arrived courtesy of Oracle.
The Register has spotted four 4.7GHz - yep, you read that right - Power6 chips cranking on Oracle 11i. The speedy chips confirm IBM's boasting that Power6 would arrive near 5GHz. They also show that IBM's customers have a lot to look forward to in terms of raw performance.
With 4.7GHz chips (4MB of L2 and 32MB of L3 cache), an IBM p570 server showed an average response time of .625 seconds when handling requests from 2,100 users. That compares to a p570 with 2.2GHz Power5+ chips that had a response time of .983 seconds for 2,000 users.
The benchmarks arrive just ahead of IBM's Power6 server launch. The rumor mill says IBM will unveil its Power6 gear, starting with midrange systems such as the p570, on Tuesday.
Thus far, IBM has been reluctant to discuss the Power6-based systems' performance. But, with chips running at 4.7GHz, IBM should clean up on a wide variety of benchmarks even if customers don't recompile their software as is needed for absolute best results with Power6.
A number of skeptics have told us that IBM will struggle in the near-term to produce 4GHz+ chips in volume. IBM, however, has been telling customers that it will have plenty of speedy chips to go around. (It looks like IBM will offer systems with 3.5GHz, 4.2GHz and 4.7GHz versions of Power6 from what we hear.)
IBM had once planned to ship Power6-based servers in 2006. It could use some new gear to go up against Sun and HP's high-end gear, which have been selling well in recent months. ®
Thanks very much to reader RG for spotting Oracle's benchmarks.
CBO - Help
Not to mention that the Cost Based Optimizer needs the table and index statistics to be valid. If your table has significant transaction traffic then the stats may be stale. If you haven't gathered stats yet, you should. Just because you have an index doesn't mean it's any good, is it the right kind of index? on the right field? What about other tables involved in the query? Oh, don't forget that using functions on fields in the where clause will tend to prevent Oracle from using indexes on those fields.
If the data that you want is scatter gun distributed through your 165 million rows, and you're retrieving a significant amount of data, even if the number of rows retrieved isn't a large % of the table, the total cost of reading the index(es) and the table reads may still be greater than the full table scan.
Self joins on the table would hurt too.
Techniques to consider;
Re: Posted Sunday 20th May 2007 07:50 GMT
The statement regarding the CBO is pointless without more information. If you are accessing more than quite a small percentage of data it IS actually MORE efficient to access it without the use of indexes, try it (if you haven't already) and see what happens with and without the index.
Even if you hint it to use an index and it is more performant for you at what cost is the performance increase? For example you may be annihilating disk IO. This might be fine in your case but is not necessarily good in every situation.
You may well have done all of this and found that actually the CBO really is choosing a bad plan - it's not unheard of, but your statement is a best misleading at worst plain wrong with out facts to back it up.
Network / Disk IO a bigger factor in DB perf
Unless you are doing heavy calculations in the DB TPS and Throughput are far more likely to be bottlenecked by your network and disk speed.
If you want something really, really fast and massively scaeable for certain classes of problem an in memory MYSQL CLUSTER plus a native threaded c++ NDB api client (eg. mod_ndb) easily beats everything else out including the commercial offerings for performance.