Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server
In article <yutra7x9dht.fsf@mew.corp.sgi.com>, Pablo Sanchez <pablo@sgi.com> writes >>>>>> "Michael" == Michael Segel <Mikey@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@sgi.com | Pg # (800) 930.5635 -or- pablo_p@pager.sgi.com >------------------------------------------------------------------------------- >I am accountable for my actions. http://reality.sgi.com/pablo [ /Sybase_FAQ ] -- David Williams