Xref: utzoo comp.unix.xenix.sco:597 comp.unix.misc:421 comp.unix.sysv386:1533 comp.unix.internals:818 comp.unix.questions:26487
Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!ub!canisius!pavlov
From: pavlov@canisius.UUCP (Greg Pavlov)
Newsgroups: comp.unix.xenix.sco,comp.unix.misc,comp.unix.sysv386,comp.unix.internals,comp.unix.questions
Subject: Re: Summary of Request for Comparison of Altos and NCR
Keywords: summary Altos NCR comparison
Message-ID: <2957@canisius.UUCP>
Date: 25 Oct 90 03:25:41 GMT
References: <11@ACT.UUCP> <YZG6DXD@xds13.ferranti.com> <505@wybbs.mi.org> <254@iphase.UUCP>
Organization: Canisius College, Buffalo N.Y. 14208
Lines: 20

In article <505@wybbs.mi.org> sleepy@wybbs.UUCP (Mike Faber) writes:
>
>Thank you.  I've been saying (to my boss mostly) that the disk speed and 
>quantity are the REAL deciding factors in a resonably designed system.
>In my opinion, the only thing you need a CPU for in a typical DBMS computer
>is to direct traffic, and make an occasional computation here and there.
>

  I don't buy that.  Once again, this is probably one of those "it depends on
  your application..." issues.  But if one has large tables on which one per-
  forms complex joins, the cpu has a lot of work to do, well beyond the 
  "occasional computation here and there...".  Computation is the least of it;
  it's the compares and other functions related to selecting the correct data
  that takes all the time, in such applications.  This is especially true if
  one has chosen his/her keys and indices carefully and accesses a good query
  optimizer (such as INGRES's, prior to Version 6...)

   greg pavlov, fstrf, amherst, ny
   pavlov@stewart.fstrf.org
   716-834-0900