Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!lll-winken!decwrl!shlump.nac.dec.com!shodha.dec.com!devine
From: devine@shodha.dec.com (Bob Devine)
Newsgroups: comp.arch
Subject: Databases and comp.arch (was: 64-bit addresses)
Message-ID: <811@shodha.dec.com>
Date: 5 Mar 90 20:06:10 GMT
References: <WAYNE.90Feb27094326@dsndata.uucp> <1786@gannet.cl.cam.ac.uk> <PCG.90Mar4213316@odin.cs.aber.ac.uk>
Organization: Digital Equipment Corp. - Colorado Springs, CO.
Lines: 17


  Databases present some problems that are not typically talked about
in comp.arch.  In contrast to many of the engineering programs that
use mainly CPU cycles and memory/bus bandwidth, databases tend to beat
on the entire system: cpu, memory, device drivers, device
interconnects, and of course, disks.

  In the cases where the database is huge, even a simple relational
select operation can flood all of memory.  In fact, memory at times
becomes more a cache for disk reads/writes than it is a workspace.

  Database comparisons currently suffer because of benchmarks that
outright lie or at least confuse the customer.  There is no SPEC-like
set of benchmarks to prevent "benchmarketing" sleeze.  A follow-on to
the Debit-Credit is in the works.  The tricks that can be done to
TP-1 make the string inlining of dhrystone look almost legal.

Bob Devine  Database Engineering  Colorado Springs, CO