Crikey! That much power might even deliver decent results despite the new Cost-Based Pessimizer!

I'm so tired of it deciding to full-table-scan 165 million rows, ignoring any and all useful indexes.

Don't IBM share fabs with AMD? If this speed bump has been achieved within sensible power/cooling constraints, it could have interesting implications for AMD's coming generation of chips.

You could have emphasised a bit more that the two systems differ in more than the power5 vs power6 chips - eg double the RAM for the power6 db machine, twice the cores in the web application machine (no idea how much that machine effected to overall performance tho). Anyway, 4.7GHz sounds impressive.

It's such a shame to waste all that horsepower on Oracle... Does that mean all of the security vulnerabilities are bypassed 60% faster? Or poorly written products lock up twice as fast?

- p6 is supposed to be power-consumption neutral compared to p5

- in the benchmarks, the p6 beast has 3000 users, compared to 2000 for the p5 beast

that should compensate the advantage of more memory quite a bit;

every session takes a meg or 2 depending on the settings of oracle.

- amd/ibm: power5 already was capable of turning parts of the chip on the backburner; rumors have it that power6 supposedly takes it a step further, perhaps putting idle processor (-parts?) on slower speed and/or other neat tricks.

still, a core is only a minor taker when it comes to power. IO-drawers, disks and cards are usually the big energy takers, wether they are processing a workload or not.

Where is the TPC-E benchmark that replaces TPC-C results now that its available? Its wonderful to see IBM continuing to support a 14 year old benchmark thats completely irrelevant to todays real workloads. TPC-C was devloped before the internet!

Wonder why availability is in late November - 6 months away??? This sounds like IBM benchmarketing all over again.

4.7GHz yields are probably in the 10's of units right now so they'll market these great new benchmark results, sell the customer on performance leadership, price it at a significant premium over standard yields (just like they did with Power5) and then, IBM will sell the customer the lower GHZ Power6 part unless you can wait till November! What a sales tactic.

Note the TPC-C 50% increase in RAM, 80% increase in storage to get this 57% better performance result!

Also note the 43% discount on the $9.4M configuration! WoW- Only $2M less than their p595 4M TPC-C result... Which is the better value? Make sure to get your discounts folks! These are pricey systems!

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.

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.

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;

partitioning

bitmap indexes