Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!mtxinu!rtech!ingres!llama!jas From: jas@llama.Ingres.COM (Jim Shankland) Newsgroups: comp.databases Subject: Re: SQL Precompilers Keywords: efficiency Message-ID: <1990Jul31.013321.5117@ingres.Ingres.COM> Date: 31 Jul 90 01:33:20 GMT References: <1990Jul26.141643.6361@dg-rtp.dg.com> <0afnkLa00UhBQ1qkxT@andrew.cmu.edu> <26518@pasteur.Berkeley.EDU> Reply-To: jas@llama.Ingres.COM (Jim Shankland) Organization: The Eddie Group Lines: 24 In article <26518@pasteur.Berkeley.EDU> mao@postgres.Berkeley.EDU (Mike Olson) writes: >In , rbw00@ccc.amdahl.com (Richard Wilmot) >writes: >> In highly repetitive systems (e.g. banking, airlines) compilation is popular >> for because one can amortize a single reptition of optimization over many >> executions of the same code. > >sharebase (formerly britton lee) supported this level of interaction when >i worked there some time ago. you could submit a query, a parsed query >tree, or a plan to the database engine from a user program. in the last >case, the engine would execute the plan. this is almost always a bad idea, >but, as you note, even bad ideas have their moments. I'd quibble with the words "almost always". Banking, airline, and other TP applications are hardly arcane applications that are "almost never" executed. In fact, at the risk of a slight overstatement, I claim that anything *other* than submitting a pre-baked query plan for execution is almost always a bad idea. Surely no-one believes that Wells Fargo Bank runs a query optimizer every time I inquire about my checking account balance? jas These are my opinions. Ingres Corp. neither knows nor cares about them.