Return-Path: mao
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA23698; Mon, 18 May 92 20:06:59 -0700
Message-Id: <9205190306.AA23698@postgres.Berkeley.EDU>
From: <mao@postgres.berkeley.edu>
Subject: Re: query optimiser info wanted
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of Tue, 19 May 92 12:03:55 EST.
             <9205190201.AA23238@postgres.Berkeley.EDU> 
Date: Mon, 18 May 92 20:11:28 PDT

In message <9205190201.AA23238@postgres.Berkeley.EDU> you write:

> Does anyone out there have any information/papers etc. about the Postgres
> query processor particularly the optimiser (if indeed this has been built
> yet). Any information would be much appreciated, as I am attempting to do
> a masters research project on Postgres and the problems associated with    
> optimising queries which invoke procedures etc. I would like to know what
> has been done so far in this area, and there is not a lot of information 
> around, it would seem, even though I have a pile of research papers almost
> up to my office ceiling already !!

the postgres optimizer is cost-based, a la "access path selection in
a relational database management system", p. selinger, proc. 1979
acm sigmod conference on management of data, june 1979.

the design of the current optmizer is described in "the design and
implementation of the postgres query optimizer", z. fong, m.sc. report,
uc berkeley, aug 1986.

joe hellerstein (joey@cs.berkeley.edu) is extending the current system
to optimize queries that invoke expensive functions; you should be able
to contact him directly for info.  in addition, a bunch of the standard
postgres publications (including stonebraker's 1989 implementation
retrospective) include details on how optimization is handled in a
type-extensible systm with user-defined types, operators, and access
methods.
					mike olson
					postgres research group
					uc berkeley
					mao@cs.berkeley.edu