wensel@postgres.uucp (Sharon Wensel) (12/20/89)
Version 1, release 2 of POSTGRES is now available for
distribution. It runs on Versions 3.4, 3.5, or 3.6 of SUN
OS for Sun 3/xxx class machines and on DECstation 3100
machines. The Lisp code has been entirely converted to C
and POSTGRES now consists of about 150,000 lines of C code.
If you would like the current system, you can get it in
one of two ways:
(1) Send a check payable to the Regents of the University
of California for $150.00 to:
Sharon Wensel
521 Evans Hall
University of California
Berkeley, CA 94720.
Indicate in your accompanying letter whether you want
the system on a 9-track tape at 1600 BPI, at 6250 BPI,
on a cartridge tape for SUN shoeboxes (QIC 24 format),
or on a TK50 DEC cartridge tape.
(2) FTP the code to your site over the ARPA net by typing
the following bracketed text without brackets. You
should see similar output.
% [ ftp 128.32.149.1 ] # or ftp postgres.berkeley.edu
Connected to 128.32.149.1.
220 postgres FTP server (Version 4.4 Sun Feb 5 07:58:07 PST 1989) ready.
Name (128.32.149.1:): [ anonymous ]
331 Guest login ok, send ident as password.
Password:[ mylogin@myhost ]
230 Guest login ok, access restrictions apply.
ftp> [ cd pub ]
250 CWD command successful.
ftp> [ binary ]
200 Type set to I.
ftp> [ get postgres-v1r2.new.tar.Z ] #Sun version
ftp> [ get postgres-DS3100-v1r2.tar.Z ] #DEC version
200 PORT command successful.
150 Opening BINARY mode data connection for postgres-v1r2.new.tar.Z (NNNNNNN bytes).
226 Transfer complete.
local: postgres-v1r2.new.tar.Z remote: postgres-v1r2.new.tar.Z
NNNNNNN bytes received in MMM.MM seconds (KK Kbytes/s)
ftp> [ quit ]
221 Goodbye.
%dmn@stiatl.UUCP (Michael Nowacki) (12/21/89)
would someone on the postgres project post a quick summary of what postgres is and what we would be likely to have if we compiled that 150k lines of c? -- Michael Nowacki gatech!stiatl!dmn Sales Technologies, Inc |\ /| 3399 Peachtree Rd, NE | \/ | Atlanta, GA (404) 841-4000 _|ike |_
mao@eden (Mike Olson) (12/28/89)
Michael Nowacki writes > would someone on the postgres project post a quick summary of what postgres > is and what we would be likely to have if we compiled that 150k lines of c? to which Steve Goldfield replies at length, quoting from the EECS research summary published here at Berkeley. Goldfield's reply was pretty much on target. In the interest of maintaining a presence for the Postgres group on the net, though, I'll add some info. I'm one of the programmers on the project. Postgres is a research project directed by Dr. Stonebraker at UC Berkeley. Stonebraker was the principal investigator for Ingres back in the seventies. Postgres is intended to extend relational systems to take advantage of likely hardware and software advances of the coming decade. The query language is called postquel; it's quel without range statements, and with syntactic support for the features described below. Architecture is client/server. A supervisory process called the postmaster (yes, even *we* get sick of all these cute "post" names) accepts requests from user processes, and starts a server (if necessary) for them. For example, if you want to use the terminal monitor (the program that accepts postquel input and displays query output), you type the command "monitor". Monitor announces to the postmaster that it needs a server; if there's no server running, the postmaster starts one and connects the terminal monitor to it. The postmaster is a relatively small process, but the server (called postgres) is pretty big, so it pays to start it only on demand. Quel-style queries work as you'd expect. In addition, the following features are visible: Versions of relations are available without any special trouble on the part of the user. That is, if you type the query retrieve (e.all) from e in emp["Apr 15 1989"] you'll see all the people who had to pay taxes last year; intervening changes won't be visible. Rules allow implementation of some integrity constraints and security controls. For example, if you say define rule rule_1 as always retrieve (emp.sal = 0) where emp.name = "Stonebraker" then you will have hidden Stonebraker's salary from anyone doing a retrieve; you can put further restraints in the where clause to qualify the user running the query, or whatever you like. Also, the query define rule rule_2 as always retrieve (e.sal) from e in emp where emp.name = "Cimarron" and e.name = "Stonebraker" will make Cimarron's salary equal to Stonebraker's salary. Updates to Stonebraker's salary will be magically propogated to Cimarron. Of course, as Stonebraker is an academic, this puts a tight cap on Cimarron's earning potential, but we must all make sacrifices in the interest of research. Rules are implemented in a way you probably don't care about, since it's (a) complicated and (b) changing in the next release. The final interesting feature in this release is the ability of users to define data types, operators, and functions for use in postquel queries. You write some code that implements your data type, operator, or function, and compile it to a .o file. You then do some hocus-pocus in postquel to get your code and the name of the data type, operator, or function registered in the system tables. You can then invoke your code from postquel. The .o file will be dynamically loaded into the execution image of postgres on demand. Links are resolved as you'd expect, so you can call postgres functions from your code. Among the features Goldfield mentions that are due in the next release: > (2) Construct an implementation for the multiple, closely coupled > processors that will be prevalent on next-generation > workstations; > (3) Provide efficient support for versions; > (6) Support triggers and inference. More specifically, we're working on archiving data to optical disk, using the rule manager to do versions of relations, revamping the rule manager to support updatable views (including new query rewrite mechanisms), and making necessary changes to the executor and optimizer. Also, we're working on a version of the planner that takes advantage of shared memory on a multi-processor system. Queries will be decomposed in a way that permits a single query to run on multiple processors; again, the executor and optimizer are getting reworked to support this. These features are due out in the next version of the code. This version of postgres represents an advance over the Lisp version we released at the beginning of 1989. It is substantially faster, more basic database support is in (indices and other stuff), and lots of bugs have been fixed. In addition, the rule manager code described above is new. Postgres is available via anonymous ftp from postgres.Berkeley.EDU (internet addr 128.32.149.1), in dir pub/. The file postgres-v1r2.new.tar.Z contains the distribution. Files postgres-setup.me and postgres-README are of interest; you should get them first and read them. If you're not on the internet, you can send a request for a tape to Sharon Wensel (wensel@postgres.Berkeley.EDU); we have some policy for sending out tapes, but I'm not sure what it is. It probably costs money. The released version runs on Decstation 3100's and Sun 3's. You are STRONGLY encouraged to send follow-up questions, bug reports, and requests to postgres@postgres.Berkeley.EDU. I will read messages sent directly to me, but can't guarantee a response anytime in the nineties. Mike Olson Postgres research group UC Berkeley mao@postgres.Berkeley.EDU PS: Hi, Michael, hope you like Atlanta better than you liked Berkeley.