Path: utzoo!mnetor!uunet!lll-winken!lll-tis!daitc!jkrueger
From: jkrueger@daitc.ARPA (Jonathan Krueger)
Newsgroups: comp.databases
Subject: Re: Quel vs SQL in Ingres 5.0
Message-ID: <42@daitc.ARPA>
Date: 10 Apr 88 04:32:33 GMT
References: <4350@ihlpf.ATT.COM> <2239@pasteur.Berkeley.Edu>
Organization: Defense Applied Information Technology Center, Alexandria VA
Lines: 45
Keywords: quel, sql, ingres
Summary: several issues involved with SQL and QUEL and ingres v5/v6



In article <2239@pasteur.Berkeley.Edu> larry@postgres.UUCP (Larry Rowe) writes:
>[in INGRES 5.0 it may take up to 10% longer to execute an SQL query,
>notably where the xacts are one-table queries, because it translates
>the SQL to QUEL.]

Our experience confirms this, usually the difference is too small to
measure.  To get an idea of how little the component of translation
contributes to the total cost of a query, try "set printqry" in your
sql terminal monitor session, this will type out the translated QUEL
and then execute the query as usual.  This is also a fun way to learn
QUEL if you know SQL.

However, two problem areas remain.

First, ABF translates SQL to EQUEL at compile time.  This is a good
thing because it removes runtime translation overhead.  But it requires
an additional pass and an additional file for each ABF frame.  Worse,
it introduces limitations on OSL/SQL, such as lack of full SQL
functionality while in OSL, and serious bugs in the OSL to ESQL/C
interface.  I think their SQL parser's ability to detect errors is also
less developed than QUEL's, leading to errors discovered at the EQUEL
or C pass, whose error messages are tougher to relate to your OSL
source.

>This issue is moot with INGRES 6.0 which has a native SQL parser in the
>backend.  I believe 6.0 is in beta release now and is expected to be
>released for production use shortly.  Check with your RTI sales rep.

Our sales rep says version 6.0 arrives on Unix before 1989, but not
much before, and only on Sun and Ultrix.  Other Unix machines, such as
ours, get it some unspecified period after that.  When we see it we'll
compare it with what other vendors have available by that time.

Second, SQL as we know it is less general than QUEL.  For instance, if
you need to update a table from another table, you may pay a
substantial performance penalty in SQL versus QUEL.  You may also pay a
penalty of increased programmer errors and lower productivity.  I don't
know how RTI can fix this and still call it SQL. At least they do offer
you a choice.

-- Jon Krueger

...uunet!daitc!jkrueger
jkrueger@daitc.arpa