Re: ** FOR IMMEDIATE RELEASE - RECORD-BREAKING TPC-C RECORD!! **

In article <47ntu8$of0@pong.lasc.lockheed.com>, Terry Greenlaw <z50816@mip.lasc.lockheed.com> wrote: > >I just can't stomach anyone trying to claim that these numbers are even >remotely related to anything that 99 percent of RDBMS users are trying >to achieve with their systems. I was not claiming this. I was explaining the tpc-c benchmark. I have never claimed 99% of users real workloads are modelled by the tpc-c benchmark. >So, let me see if I've got this straight. I'm trying to purchase a database >for my company. An example of real-world constraints would be: >1) I have $1,500,000 to spend >2) I have 100-120 concurrent users >3) My entire database is currently 20GB with approx. 15% growth/year > >And you're claiming a realistic benchmark can be found by: >1) Picking the result you want >2) Making the database big enough to support your hypothesis >3) Making the number of users large enough to support your hypothesis >4) Buy sufficient additional components to support n users Nope. Again you are twisting my words. I explained to you how the tpc-c benchmark was typically run as one of your previous posts implied you did not understand either the test or its intentions. You argued that the benchmark was not controlled and that vendors were doing stuff with "smoke and mirrors". I argued that you are wrong on this point. The benchmark is tightly controlled and almost everything done by the vendors is because the benchmark mandates doing such things. >All I wanted to know was what kind of performance I should expect from >machine X running database Y relative to machine Q or database Z. Isn't >that the purpose of a benchmark? If that is all you wanted to know, then why do you bring up all the other constraints? The benchmark does provide some evidence about which systems are faster than others, especially if you can find numbers comparing different RDBMS on the same hardware or the same RDBMS on different hardware. >All the TPC-C numbers I've seen to date are for unrealistic business >environments. My car goes 130 MPH and uses no gas. Did I mention I >dropped it out of a B-52 bomber? The environments may be unrealistic but they are definately extreme. That is to say that they probably represent the worst case. They produce the extremely large demands on the system under test. Just because your particular environment is much smaller and simpler doesn't mean the benchmark isn't measuring what it was intended to measure. Your analogy is flawed. A more similar analogy (if you insist upon using cars) is the most recent Car and Driver issue. In it they compare a camaro against a mustang in several tests: drag racing and an open track being two of these. Nobody would argue that this is how one should decide which car to buy (because these tests don't realistically simulate normal driving conditions) but it does accurately test the both cars at their limits. To continue the analogy, you would then reply that these tests are bogus because 99% of users don't drive on open tracks. Of course that is true but you have missed the point. The point is to illustrate the system behavior under extreme conditions. One would hope an intelligent user would use more than a tpc-c benchmark number to select an RDBMS. Pat