More on TPC-C & Clustered Indexes
Prime & Oracle published another TPC-C benchmark this morning, achieving 1.2M transactions per minute @ $3.94 tpmC. This pushes HP & SQL Server's top result down to 4th & leaves SQL Server with only one result in the top 10 TPC-C benchmarks. Not a great place to be in the benchmarking game.
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=all
Note that this benchmark also implements table hash clusters rather than index organised tables (page 201 in the full disclosure report). Using hash clusters is a "direct to block" technology which means that the database engine doesn't have to waste time either reading or locking clustered index pages whilst performing high speed transactions. Instead, blocks are located by hashing the primary key values of rows being accessed directly to the block (page) number - a huge advantage over SQL Server's Clustered Index approach.
SQL Server needs to catch up in this area if it wants to maintain industry recognition as a hgh performance transaction processing database engine.
DB2 & Oracle both implement direct to block technologies whilst the SQL Server offers no comparable feature. I am amazed that those who configure the SQL Server TPC-C benchmarks implement expensive composite Clustered Indexes during benchmarking given the strong trend against these expensive index lookup mechanisms - surely it would be more efficient to at least use heap structures & cut out the expensive extra IX bookmark lookups in future SQL Server TPC-C benchmarks.
Note also that this latest Oracle benchmark uses half the number of CPUs (32) than SQL Server's top result, which uses 64 CPUs yet still achieves more throughput. This leaves me wondering what Oracle could publish if they used 64 CPUs.
I also really hope the guys in the SQL Server team focus more on improving the efficiency of access methods in up-coming releases. Clustered Indexes & Heaps no longer seem sophisticated enough to keep up with the alternatives today.