Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server
Posted in 1997
In article <yuthg8sae8y.fsf@mew.corp.sgi.com>, Pablo Sanchez <pablo@sgi.com> writes >>>>>> "David" == David Williams <djw@smooth1.demon.co.uk> writes: >David> >David> Imagine 1 page with 2 rows one it. >David> >David> 1. Page level locking >David> >David> User A updates row 1 >David> At the same time user B updates row 2. User B has to wait for >David> User B to commit. >David> >David> 2. With row level locking >David> User A updates row 1 >David> User B updates row 2 (with no waiting). >David> >David> How can 1 be faster than 2 if user B has to wait? > >You're forgetting the RDBMS's latency to acquire and release >locks for the rows. It all adds up and offsets the gain. >You can't just look at a small piece of *anything*. You >have to, pardon my Boulderism, look at the problem holistically. > The latency would be different? Both times user B takes out 1 lock. >>> 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: >>> >David> I checked the results, these figure come from different machines. >David> So Sybase runs their TPC benchmarks on larger hardware..so? > >If your first example had validity, then your above >statement wouldn't matter. A faster machine would mean that >you'd get to the wait that much faster, but that's not what >is happening. We're seeing that Sybase is scaling with the >hardware provided. > But if the machine is much larger the wait becomes insigificant compared to the increase in CPU power and I/O performance. >You buy a bigger machine to get more throughput... > >>> For a finely tuned application, row level locking >>> does *not* matter. >David> Lock granularity is still a problem. Why do UNIX kernels lock >David> individual files and data structures rather than having one large >David> kernel lock? > >We're not talking database locks versus page level/row >level. We're talking page level and row level. There lies >the difference. -- David Williams