Path: utzoo!attcan!uunet!decwrl!ucbvax!pasteur!eden!mao From: mao@eden (Mike Olson) Newsgroups: comp.databases Subject: Re: SQL Precompilers Keywords: efficiency Message-ID: <26518@pasteur.Berkeley.EDU> Date: 27 Jul 90 16:05:09 GMT References: <1990Jul26.141643.6361@dg-rtp.dg.com> <0afnkLa00UhBQ1qkxT@andrew.cmu.edu> Sender: news@pasteur.Berkeley.EDU Reply-To: mao@postgres.Berkeley.EDU (Mike Olson) Followup-To: comp.databases Organization: University of California, Berkeley Lines: 25 In , rbw00@ccc.amdahl.com (Richard Wilmot) writes > While it is true that query efficiency can suffer from reliance on out-of- > date population and value distribution statistics, there are many > applications where dynamically determining the access path is not efficient. > The type of transaction used in the TPC benchmarks, for example, will > benefit markedly from precompiling (by the query optimizer) the database > accesses. TPC benchmarks are very short financial update transactions. > ... > 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. mike olson postgres research group uc berkeley mao@postgres.berkeley.edu