Path: utzoo!attcan!uunet!peregrine!elroy!ames!lll-tis!daitc!jkrueger
From: jkrueger@daitc.ARPA (Jonathan Krueger)
Newsgroups: comp.databases
Subject: Re: measuring speed (was: Oracle on the cheap)
Message-ID: <149@daitc.ARPA>
Date: 1 Aug 88 23:50:39 GMT
References: <5165@dasys1.UUCP> <8208@ncoast.UUCP> <178@turbo.oracle.UUCP> <590@hscfvax.harvard.edu> <180@turbo.oracle.UUCP> <11956@ncoast.UUCP>
Reply-To: jkrueger@daitc.UUCP (Jonathan Krueger)
Organization: Defense Applied Information Technology Center, Alexandria VA
Lines: 27

In article <11956@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes:

>Frankly, whatever supposed benefit you get from SQL is lost when you
>have to pass character SQL statements down a pipe or through shared
>memory to be parsed at runtime and then get the data back the same
>way....Unify ESQL is translated _at_compile_time_ into the same
>low-level C code... which makes for blinding speed compared to runtime
>parsing of complex grammars.

Could you quantify "blinding speed", please?  Your argument would be
best supported by numbers which measure the different costs of
executing queries, including compiling the C code where necessary.

>an application that had been running
>in 3.3 for years slowed down abruptly when moved into Oracle....  (Again,
>SQL parsing and shipping data through (pipes|shared memory) has disastrous
>effects on speed.

Many overheads change when you move from one product to another.  How
do the costs break down?

-- Jon

-- 
Jonathan Krueger  uunet!daitc!jkrueger  jkrueger@daitc.arpa  (703) 998-4777

Inspected by: No. 15