Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server

In article <3483728B.7651_at_agd.nsw.gov.au>, no_sp.am_at_agd.nsw.gov.au says...
>
>Gary L. Burnore wrote:
>>
>> On 01 Dec 1997 10:31:26 -0700, Pablo Sanchez <pablo_at_sgi.com> wrote:
>>
>> [TPC-C results ...]
>>
>> Of course it's not your point. Your point is obvious. Were INFORMIX's
>> published numbers higher, you'd be speaking a different tune, no?
>
> You seem to be missing the point. Try reading up on the
> specs of the TPC-C benchmark. Check out the TPC site.
>
How easy a constructive debate degrade to religous wars :-/

> The real point is that RLL isn't critical to an application.
> I think this is what Pablo has been trying to get across.
>
Right, this is the debated issue. Informix and Sybase TPC-C results is only relevant as an argument for PLL-only not degrading performance. We could possible compare some other RLL-able RDBMS with some other PLL-only RDBMS to get the same argument across.

Many of us has stated the assumption that 'the finer lock granularity' the better concurrency. To me this seems obvious.

Pablo has stated that this assumption does not hold for a 'finely tuned application'. He states that this is proven by TPC-C results because these show that the TPC-C application does not have its performance degraded by a PLL-only RDBMS. IMHO, the TPC-C results does not prove Pablos point.

The only thing the TPC-C proves is that there exists at least one application for which RLL / PLL is not an issue. I can see no proof whatsoever for this being true for all 'finely tuned' applications.

The TPC-C consists of five transactions, four 'noisemakers' and one measurement transaction. Essentially the noisemakers are run to create a load on the RDBMS and then it is measured how many 'measurement transactions' can be run per minute under that load. Two of the 'noisemakers' are select-only. These transactions are described on six pages in the TPC-C spec appendix A, well worth reading. Get it from www.tpc.org.

The TPC-C transactions are all 'self-contained', there is no user interaction within a transaction. It seems to me they are also 'very short'. A single transaction in TPC-C is not complex or takes a long time. What is measured is therefore how the RDBMS performs under an ever increasing load of 'very short' transactions. It is not surprising that degradation due to each transaction locking pages instead of rows becomes negligable.

It would be very interesting seeing a test that measured how an RDBMS performed under the load of transactions of ever increasing complexity. My guess is that lock-granularity would become much more of an issue in such a test.

We have seen a number of examples in this thread of applications that would benefit from RLL. My point is that the TPC-C alone is not enough to state that these examples are irrelevant.

/Johan

-- 
 ________________________________________________________________________
| >>> The opinions herein are mine and not neccessarily my employers <<< |
| Johan Andersson, Msc CSE                               jna_at_carmenta.se |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~