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

Johan Andersson wrote: > > In article <3483728B.7651@agd.nsw.gov.au>, no_sp.am@agd.nsw.gov.au says... > > > 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. Do you have any examples? > Many of us has stated the assumption that 'the finer lock granularity' the > better concurrency. To me this seems obvious. And increasing concurrency gives you ... ? > 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. Do you have any examples where its not the case for a 'finely tuned' application? > 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. TPC-C mimics OLTP applications (which is what you've described). I don't know of any OLTP applications that are batch jobs. Do you? > 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. Do you know of any applications that run with ever increasing complexity? An OLTP application does essentially the same thing over and over. Only its data changes. > 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. Which examples whould they be? I haven't seen one concrete example yet that absolutely mandates RLL. -am