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

Johan Andersson wrote:
>
> In article <3483728B.7651_at_agd.nsw.gov.au>, no_sp.am_at_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 Received on Wed Dec 03 1997 - 00:00:00 CET