Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!bingvaxu!leah!uwmcsd1!grc!don
From: don@grc.UUCP (Donald D. Woelz)
Newsgroups: comp.databases
Subject: DATABASE ACCELERATOR
Message-ID: <740@grc.UUCP>
Date: Fri, 18-Sep-87 17:45:13 EDT
Article-I.D.: grc.740
Posted: Fri Sep 18 17:45:13 1987
Date-Received: Sun, 20-Sep-87 12:28:07 EDT
Reply-To: don@grc.UUCP (Donald D. Woelz)
Followup-To: {rutgers, harvard, ames, seismo}!uwvax!uwmcsd1!grc!don
Organization: GENROCO, Inc., Slinger, WI
Lines: 33
Keywords: database accelerator search sort

We are in the process of specifying and designing a hardware database
accelerator.  This product will be capable of doing searches and/or
sorts at extremely high speeds (100 to 200 times faster than the CPU
would be capable of).

My question to the net is this:  What do people who design database
software believe to be the bottlenecks to performance?

This ends up being a lot of questions.  What percentage of time is
spent searching? Sorting?  The two are inter-related, so which one
would be more important to the database designer to have optimized?
What are the parameters of most database searches in terms of the 
lenght of the keys?  The length of the records?  Are the records
mostly fixed length or variable length?  The same questions apply
to sorting.

Would a database designer be particularly put out if there were
restrictions such that a certain record length will produce (say) 5 times
more performance than another record length (for instance record
lengths that are 2**N bytes long, or have an even number or bytes)?

I don't think I have even begun to scratch the surface on the questions
that have to be answered (or asked?), but I would appreciate any input
from knowledgeable people on this topic.  If you email me your
responses, I will summarize and post to the net at some time in the
future.

Thanks
Don Woelz
GENROCO, Inc.
*********************************************************
{rutgers, harvard, ames, seismo(?)}!uwvax!uwmcsd1!grc!don
*********************************************************