TPC-H for p6-based 595 with...

I hate to repeat myself, but it looks like another example of "I can't read, but somehow i wasn't able to understand".

1. I just posted the message of the withdrawal, because i referred to the TPC-H result a few days earlier. Without this article such an withdrawal wound be worth a blog entry. TPC often looks like a shark tank to me, so withdrawal messages are just a sign for me that someone had the luck to find an error in someone else result.

2. I don't know why the ParAccel has been withdrawn. And i don't ask for the reasons out of the same reasons why i'm not asking for the reasons behind the IBM withdrawal. AFAIK as i know, such things are confidential to the TPC and even when i'm asking i can't write about them.

I could speculate about that: But before pointing to Oracle i wouldn't rule out other companies in the column-based storage. This market is pretty competitive at the moment and i assume a good TPC-H result could harm sales of others, thus you search for problems to remove the result.

When i should speculate about the withdrawal of the TPC-H result of IBM: Perhaps they recognized, that the same problem like the ParAccel people and removed it, before they are forced to do so.

But who knows, and if i knew i could not tell you that i know. I'm just speculating.

3. It looks like, you have strong dislike for Oracle. Sometimes such a dislike can hide the obvious from the sight.

At first you should first think about the device that was used by ParAccel. When my memory serves my right, it consisted out of 43 X4540. 86 Opteron Quadcores, 2064 disks, 2.6875 Terabyte of memory, 2064 SATA controllers on 258 controllers, connected to 258 PCIe-controllers, connected to 86 Hypertransport-Channels. It's impressive how inexpensive such configurations got in the recent time.

When my memory services me right, large heaps of the TPC-H queries were simply executed in memory and of course every database is really f*cking fast when having such amounts of memory to do it's work. Even when compared with the most expensive SSD.

Memory saturated databases or databases with enough memory to store the actual working set are extremely fast. Even really bad databases or databases with badly chosen indices. And then there were the vast amount of disks: A petabyte for an 30 TB TPC-H scale factor. Enough heads to spare at columnar store, that is really benevolent to the distributed on several system.

Furthermore you surely know, that Exadata V2 as a OLTP/DWH system isn't comparable to specialized databases for DHW, albeit Exadata V2 starts to use methods similar to the ones in those specialized. Use a pure columnar store database for OLTP loads, and you will see the shortfalls. That's the reason why many people divide their BI databases from their regular transaction databases. From my point of view the BI Appliance from SAP is a good example for this. Using regular OLTP for the normal work and using an appliance with an in-memory database to speed up business-intelligence

To close this comment: I do not think that you can draw any conclusion from the widthdrawal. And BTW: Did you have seen TPC-H results for the Exabyte device to proof your speculation?

4. There is a simple reason, why i don't believe that one of the big-guns forced the withdrawal of the results: It's by any measure the worst method to counter a benchmark result and you are a good example: Even when the result has been withdrawn the people remember the result. Such an result is like toothpaste, you can't get it back to the tube, even when rules have ordered it to do so ...