Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!van-bc!tfic.bc.ca!clh
From: clh@tfic.bc.ca (Chris Hermansen)
Newsgroups: comp.databases
Subject: Re: SQL Precompilers
Message-ID: <1990Aug8.151303.11352@tfic.bc.ca>
Date: 8 Aug 90 15:13:03 GMT
References: <1990Jul31.013321.5117@ingres.Ingres.COM> <10388@sybase.sybase.com>
Reply-To: clh@tacitus.UUCP (Chris Hermansen)
Organization: Timberline Forest Inventory Consultants
Lines: 28

In article <10388@sybase.sybase.com> jeffl@sybase.Sybase.COM (Jeff Lichtman) writes:
>>>...or a plan to the database engine from a user program...
>>>this is almost always a bad idea...
>> I claim that anything *other* than submitting a pre-baked query plan for
>> execution is almost always a bad idea...
>
>Precompiled queries are good.  I believe (please correct me if I'm wrong)
>that the original posting was talking about user-written query plans
>hard-coded into applications and sent to the server.  The problem here
>is that the compilation and plan storage are being done in the wrong
>place.  It's much better for the DBMS to compile and keep the plan,
>so all the user has to do is invoke it by name.

Why not some make-like software in the middle that senses when it needs
to recompile/reoptimize the query based on some dependencies (ie the entry
in the tables table is newer than the precompiled query) and/or some
size related rules based on the table sizes at compile time (which could
possibly be stored with the precompiled query)?  That way, if the short
table became longer, or the schemae changed, or ...

All this said by someone not knowing much about query optimization.

Chris Hermansen                         Timberline Forest Inventory Consultants
Voice: 1 604 733 0731                   302 - 958 West 8th Avenue
FAX:   1 604 733 0634                   Vancouver B.C. CANADA
clh@tfic.bc.ca                          V5Z 1E5

C'est ma facon de parler.