PPOOSSTTGGRREESS VVeerrssiioonn 44..11 RReelleeaassee NNootteess 11999933//0022//2255 11.. IInnttrroodduuccttiioonn These are the release notes for version 4.1 of the POST- GRES database system from UC Berkeley. The database sys- tem and its installation procedure are covered in detail in the setup document for this release, which can be found in the file ......//ddoocc//ppoossttggrreess--sseettuupp..{{ccaatt,,ppss}}. Here, we highlight some of the major changes. 22.. AAiimm This release has both extensive superficial changes, such as the layout of the source tree and associated build pro- cedures, and major new pieces of functionality. 33.. EExxiissttiinngg 44..00..11 DDaattaabbaasseess There have been major changes to the tuple header struc- tures and the system catalogs since POSTGRES Version 4.0.1. Because of this if you want to migrate your data from Version 4.0.1 you must copy all your databases out to flat ASCII files and then reload them into the 4.1 database directory. See the ccooppyy command in the reference manual for details about how to copy data out of a class into a flat ASCII file. 44.. SSuuppeerrffiicciiaall CChhaannggeess The layout of the source tree has been restructured for this release. All of the source code for the system including the reference manual and documents lies below the ssrrcc// directory at the top level. The remainder of the directories at the top level contain a completely installed POSTGRES system suitable for use on the selected platform. Since we are only officially supporting two platforms, we thought we'd give this a shot and see if it works. In theory this allows you to get running right away without compiling the sources. If you opt to run this pre-installed system, we urge you to re-compile the system from scratch should you run into any problems. This is a test, as they say. Underneath the ssrrcc// directory there are subdirectories corresponding to the major components of the system. There are Makefiles everywhere for building the system. PPOOSSTTGGRREESS VV44..11 RReelleeaassee NNootteess 22 11999933//0022//2255 This release uses a new version of make called bbmmaakkee; the source (and executable) is provided with the release (see ......//ddoocc//ppoossttggrreess--sseettuupp..{{ccaatt,,ppss}}). The file ......//ssrrcc//MMaakkeeffiillee..gglloobbaall is a general configuration Make- file that is included by all the other Makefiles, and has knobs and buttons to tailor this release to your specifi- cation. In general, wherever a MMaakkeeffiillee..gglloobbaall exits, it is included by the Makefile in that directory and by any Makefiles in any subdirectories. Running bbmmaakkee at a top level will run all Makefiles in any subdirectories too. A few exceptions to this are the ddoocc, rreeff, rreeggrreessss, and ttoooollss directories. Rebuilding the reference manual and manpages in ddoocc and rreeff requires that groff and friends be installed on your system, so we thought it best to leave these out by default. To build them you can ccdd into the directory and type bbmmaakkee iinnssttaallll to explicitly build them. Or you can edit ssrrcc//MMaakkeeffiillee to add them by default. The rreeggrreessss directory runs demos, benchmarks, and regression tests, which can potentially take hours to run -- so we thought it best to leave them out as well. The ttoooollss directory contains the source for the bbmmaakkee program, which is a bootstrap piece of sorts. If you can't use the pre- compiled version of bmake, then you'll have to recompile it in here. It's all in the ppoossttggrreess--sseettuupp document. Structurally, the ssrrcc// directory contains the following major systems: bbaacckkeenndd - Code for the backend and postmaster, including all header files. bbiinn - All the support programs, including shell scripts and executables. ccoonnttrriibb - User contributed software. lliibbppqq - Frontend library code (produces libpq.a and copies out header files). The oolldd__ddoocc directory contains *roff source for documents that we didn't have time to convert to our new build sys- tem, but which we thought might come in handy for refer- ence. Should you take the time to make this work and pro- duce Makefiles for these documents, please forward them to us. You might also notice directories called oobbjj// scattered throughout the source tree. These directories are used by bmake as a place to store the output of compilations and for temporary files. Here at Berkeley we have a special scheme that allows us to share sources with multiple hosts and platforms and build off the same source tree by having bmake do all its work in these oobbjj// directories. On our master source tree these oobbjj// directories are not real directories, but pointers to local storage on our PPOOSSTTGGRREESS VV44..11 RReelleeaassee NNootteess 33 11999933//0022//2255 workstations. When we produce the release, we turn these files back into real directories. In general, it keeps the source tree cleaner to have all the objects and exe- cutables stored down a layer in the oobbjj// directory. We regret that we are not supporting this mechanism for multi-client / single source builds yet, but may do so in a future release if there is interest expressed by the user community. 55.. NNeeww FFeeaattuurreess 55..11.. UUsseerr AAuutthheennttiiccaattiioonn This release supports user authentication using the kkeerr-- bbeerrooss system distributed by MIT. By default this system is disabled, but can be enabled by turning on the fea- ture in ssrrcc//MMaakkeeffiillee..gglloobbaall. It requires that you have installed kerberos at your site. The kerberos code is not supplied with this package. See the file ......//ddoocc//kkeerrbbeerrooss..ffaaqq. Also, refer to the reference man- ual for details. 55..22.. AAcccceessss CCoonnttrrooll POSTGRES provides new mechanisms to allow users to limit the access to their data that is provided to other users. See the reference manual under AACCCCEESSSS CCOONNTTRROOLL for details. 55..33.. UUnnttrruusstteedd FFuunnccttiioonnss Support has been added for designating a user-defined function as "untrusted", which means that the backend will not crash if the function fails, and that the func- tion will run in a separate address space from the back- end. See the ddeeffiinnee ffuunnccttiioonn command in the reference manual. 55..44.. PPrreeddiiccaattee MMiiggrraattiioonn AAllggoorriitthhmm Version 4.1 supports the complete Predicate Migration Algorithm as described in the literature [JMH92, HS93]. This means that the POSTGRES optimizer now produces optimal plans for queries that contain expensive func- tions in the wwhheerree clause. BUGS: The Predicate Migration Algorithm assumes that function results can be cached. Since function caching has not yet been implemented, the results of Predicate Migration may be suboptimal in some situations, particu- larly for queries that contain both expensive restric- tions as well as joins that produce more tuples in the PPOOSSTTGGRREESS VV44..11 RReelleeaassee NNootteess 44 11999933//0022//2255 output than in the inputs (e.g. cross-product joins, joins on operators other than =, etc.) Referrences: [JMH92] Joseph M. Hellerstein, "Predicate Migration: Optimizing Queries With Expensive Predi- cates", University of California, Berkeley, Tech Report Sequoia 2000 92/13, December, 1992. [HS93] Joseph M. Hellerstein, Michael Stonebraker. "Predicate Migration: Optimizing Queries With Expensive Predicates", to appear Proc. ACM-SIGMOD International Conference On Management of Data, 1993. 55..55.. UUbbiiqquuiittoouuss TTiimmee TTrraavveell Version 4.1 includes an initial implementation of ubiq- uitous time travel for POSTGRES. Previous releases allowed the user to do time travel on data, by writing queries of the form rreettrriieevvee ((ee..aallll)) ffrroomm ee iinn eemmpp[[""JJaann 11 11999922""]] In the current release, this notion of time travel is extended to include operators and functions. For exam- ple, in POSTGRES 4.1, the query rreettrriieevvee ((hhiigghheerr__ssaall == 11..11 ** ee..ssaallaarryy)) ffrroomm ee iinn eemmpp[[""JJaann 11 11999922""]] will use the multiplication (**) operator that existed as of Jan 1, 1992. The operator is chosen to match the time qualification applied to the data on which it oper- ates. Multi-table queries in which all of the tables have dif- ferent time qualifications make it difficult to choose the time that should be used when looking up operators or functions. Because of this, time travel on operators and functions is only applied to queries on single tables. This restriction will be removed in a subse- quent release of POSTGRES. 55..66.. PPaarrttiiaall IInnddeexxeess POSTGRES now supports partial indexes, which index only those instances in a class that satisfy a specified predicate. A partial index can be extended to cover more instances or to become a complete index. Partial indexes cannot satisfy as wide a range of queries as complete indexes, but they can be built more quickly, especially if the index key is an expensive function. See the ddeeffiinnee iinnddeexx((ccoommmmaannddss)) and eexxtteenndd iinnddeexx((ccoommmmaannddss)) sections of the reference manual for PPOOSSTTGGRREESS VV44..11 RReelleeaassee NNootteess 55 11999933//0022//2255 more details. 66.. NNoott YYeett BBuutt SSoooonn 66..11.. SSeettss The implementation of sets planned for the 4.1 release of Postgres is not yet stable enough to distribute. It will be completed and released separately within approx- imately 1-2 months. Initially, sets will contain tuples produced as the result of some query. The user will define a set by specifying the query which produces the tuples she wants in the set. A more complete descrip- tion will be provided when the implementation of sets is released. 66..22.. FFuunnccttiioonn PPrroottoottyyppeess We plan to produce function prototypes for the entire source tree for the next release. We decided that we will completely convert without providing backward sup- port for traditional C because all the mechanisms that provide backward support are ugly beyond description (and still have problems with narrow argument passing). If you feel that you will be seriously impacted by this -- we would like to hear from you.