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

From: David Williams <djw_at_smooth1.demon.co.uk>
Date: 1997/12/02
Message-ID: <ccCyLBAQiGh0EwC7_at_smooth1.demon.co.uk>#1/1


In article <yuten3wab3j.fsf_at_mew.corp.sgi.com>, Pablo Sanchez <pablo_at_sgi.com> writes
>>>>>> "David" == David Williams <djw_at_smooth1.demon.co.uk> writes:
>David>
>David> The latency would be different?
>
>Sure, the respective lock managers need to deal with
>different issues due to page vs row lock handling along with
>any existing locks. With page level, there are typically
>less locks for the lock manager to have to manage.
>
>David> But if the machine is much larger the wait becomes insigificant
>
>Not really. If we have a latency issue, we simply aggravate
>the problem with a faster machine. We get the CPU portion
>of the execution done faster so we end up at the point of
>contention sooner. Therefore the faster the machine,
>typically, the more glaring the problem.
>
  But the look what happends during the wait time. It all centres   around the lock table in memory and it is all CPU execution and   CPU->memory/memory->CPU transfers.

  Faster machine = faster CPU execution + faster CPU/memory transfer

  =...  

  lower wait times

  =... higher TPC.

  You saying my Turing machine which executes

  1 CPU instruction per minute
  1 CPU<-> memory transfer per minute

  would have a longer wait time than a Sun sparc box???        

>That's why I cite the TPC-C's. Even though we have
>different machines, we see that Sybase is scaling well and
>the resource contentions are being dealt with. Now note the
>version and availability of the version of Sybase for the
>TPC-C report. Way out in the future. Typically this is
>because of issues found during the benching with the RDBMS
>and the O/S. Scaling issues...
>
>Take care.
 

-- 
David Williams
Received on Tue Dec 02 1997 - 00:00:00 CET

Original text of this message