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

In article <yutra7x9dht.fsf_at_mew.corp.sgi.com>, Pablo Sanchez <pablo_at_sgi.com> writes
>>>>>> "Michael" == Michael Segel <Mikey_at_NOSPAM.King.of.MyDomain.NOSPAM.Segel.com
>> writes:
>Michael>
>Michael> [ examples deleted ]
>Michael>
>Michael> True, you can write these with page level locks,
>Michael> however you won't get the performance, and you will
>Michael> have to write extra code to compensate.
>
>What do you base your assertion that "you won't get the
>performance"? The applications you talked about are all
>applications that require a highly tuned application in
>order to get excellent performance.
>

  Imagine 1 page with 2 rows one it.

1. Page level locking

   User A updates row 1
   At the same time user B updates row 2. User B has to wait for    User B to commit.

  2. With row level locking
   User A updates row 1
   User B updates row 2 (with no waiting).

  How can 1 be faster than 2 if user B has to wait?

>If you look at the TPC-C's (as I've mentioned, before)
>you'll see another highly tuned (OLTP) application. If I
>compare the *currently* submitted numbers for Sybase
>vs Informix I see the following:
>
> Sybase..... 39,469 tpmC
> Informix... 24,309 tpmC
>
>That's a 62% performance increase by using Sybase. Now I
>grant you that I believe that we'll see Informix
>Inc. publishing even higher numbers but that's not my
>point. My point is:
>
  I checked the results, these figure come from different machines.   So Sybase runs their TPC benchmarks on larger hardware..so?

> For a finely tuned application, row level locking
> does *not* matter.
  Lock granularity is still a problem. Why do UNIX kernels lock   individual files and data structures rather than having one large   kernel lock? Try reading

  UNIX Systems for Modern Architectures
  Sysmmetric Multiprocessing and Caching for Kernel Programmers   by Curt Schimmel
  Addison-Wesley
  ISBN 0-201-63338-8   "If the processes in the application job mix use seperate kernel    resources, each of whose data structures are protected by separate    locks, then these processes will not contend for the same locks and    will be able to run simultanueously on different CPUs, whether they    are in user or kernel mode"

   Translate to databases and internal data structures.

>
>The numbers don't support it.
 

>
>I don't see you producing any factual data to prove your
>point. I'd be more than happy to look at any factual and
>objective data you produce.
>
>As for writing "extra code to compensate", this is a
>subjective remark. I think the code difference between the
>two is minor enough...
>
>Michael> Sorry Pablo, defend Sybase on another point. Surely
>Michael> there are things that Sybase does that Informix
>Michael> can't right? I mean, take Oracle for instance. They
>Michael> have some neat indexing techniques that Informix
>Michael> lacks.
>
>Honestly, this has nothing to do with Sybase. It has to do
>with marketing hype as I've said all along. You've
>swallowed the row-level is better than page-level pill. It
>sorta makes sense but unfortunately the facts don't support
>it. It's marketing hype.
>
>* TPC information can be gleaned from www.tpc.org
>--
>Pablo Sanchez | Ph # (650) 933.3812 Fax # (650) 933.2821
>pablo_at_sgi.com | Pg # (800) 930.5635 -or- pablo_p_at_pager.sgi.com
>-------------------------------------------------------------------------------
>I am accountable for my actions. http://reality.sgi.com/pablo [ /Sybase_FAQ ]
 

-- 
David Williams