Currently, POSTGRES is about 90,000 lines of code in C and is being used by assorted "bold and brave" early users. The system has been constructed by a team of 5 part time students led by a full time chief programmer over the last three years. During this period, we have made a large number of design and implementation choices. Moreover, in some areas we would do things quite differently if we were to start from scratch again. The purpose of this paper is to reflect on the design and implementation decisions we made and to offer advice to implementors who might follow some of our paths. In this paper we restrict our attention to the DBMS "backend" functions. In another paper some of us treat PICASSO, the application development environment that is being built on top of POSTGRES. 1. INTRODUCTION Current relational DBMSs are oriented toward efficient support for business data processing applications where large numbers of instances of fixed format records must be stored and accessed. Tr...

Abstract not found

. The traditional focus of relational query optimization schemes has been on the choice of join methods and join orders. Restrictions have typically been handled in query optimizers by "predicate pushdown" rules, which apply restrictions in some random order before as many joins as possible. These rules work under the assumption that restriction is essentially a zero-time operation. However, today's extensible and object-oriented database systems allow users to define time-consuming functions, which may be used in a query's restriction and join predicates. Furthermore, SQL has long supported subquery predicates, which may be arbitrarily time-consuming to check. Thus restrictions should not be considered zero-time operations, and the model of query optimization must be enhanced. In this paper we develop a theory for moving expensive predicates in a query plan so that the total cost of the plan --- including the costs of both joins and restrictions --- is minimal. We present an algorithm to implement the theory, as well as results of our implementation in POSTGRES. Our experience with the newly enhanced POSTGRES query optimizer demonstrates that correctly optimizing queries with expensive predicates often produces plans that are orders of magnitude faster than plans generated by a traditional query optimizer. The additional complexity of considering expensive predicates during optimization is found to be manageably small. 1

We define an algebra which synthesizes relational query concepts with object-oriented databases. The algebra fully supports abstract data types and object identity while providing associative access to objects, including a unique join capability. The operations take an abstract view of objects and access typed collections of objects through the public interface defined for the type. The algebra supports access to relationships implied by the structure of the objects, as well as the definition and creation of new relationships between objects. The structure of the algebra and the abstract access to objects offer opportunities for query optimization. 1 Introduction Object-oriented databases are emerging in response to a requirement for more complete modelling of complex data in modern design and office environments. Such databases attempt to combine the modelling power of object-based programming models with traditional database concepts such as persistence, data sharing, cons...

ODE is a database system and environment based on the object paradigm. It offers one integrated data model for both database and general purpose manipulation. The database is defined, queried and manipulated in the database programming language O++ which is based on C++. O++ borrows and extends the object definition facility of C++, called the class. Classes support data encapsulation and multiple inheritance. We provide facilities for creating persistent and versioned objects, defining sets, and iterating over sets and clusters of persistent objects. We also provide facilities to associate constraints and triggers with objects. This paper presents the linguistic facilities provided in O++ and the data model it supports. 1. INTRODUCTION The object paradigm is a natural way of organizing data as it allows users to structure, retrieve and update data in terms of the application domain. ODE is a database system and environment based on the object paradigm. The database is defined, queri...

E is an extension of C++ designed for writing software systems to support persistent applications. Originally designed as a language for implementing database systems, E has evolved into a general persistent programming language E was the first C++ extension to support transparent persistence, the first C++ implementation to support generic classes, and remains the only C++ extension to provide general-purpose lterators, In addition to its contributions to the C + + programming domain, work on E has made several contributions to the field of persmtent languages in general, including several distinct implementations of persistence. Thm paper describes the main features of E and shows through examples how E addresses many of the problems that arise in building persistent systems.

In a multidatabase environment with mobile computers involved, the nature of computing is such that the user may not wait for the submitted global transaction to complete before disconnecting from the network. In this paper, a basic architectural framework to support transaction management in multidatabase systems is proposed and discussed. A simple Message and Queuing Facility is suggested which provides a common communication and data exchange protocol to effectively manage global transactions submitted by mobile workstations (MWS). The state of global transactions is modelled through the use of transaction sub-queues. The proposed strategy allows an MWS to submit global transactions and then disconnect itself from the network to perform some other tasks thereby increasing processing parallelism and independence. 1 Introduction With the decentralisation of business enterprises, there is a shift in the processing requirements: from online processing environment accessing a centralise...

When a query fails, it is more cooperative to identify the cause of failure, rather than just to report the empty answer set. If there is not a cause for the query's failure, it is worthwhile to report the part of the query which failed. To identify a minimal failing subquery (MFS) of the query is the best way to do this. (This MFS is not unique; there may be many of them.) Likewise, to identify a maximal succeeding subquery (MSS) can help a user to recast a new query that leads to a non-empty answer set. Database systems do not provide the functionality of these types of cooperative responses. This may be, in part, because algorithmic approaches to finding the MFSs and the MSSs to a failing query are not obvious. The search space of subqueries is large. Despite work on MFSs in the past, the algorithmic complexity of these identification problems had remained uncharted. This paper shows the complexity profile of MFS and MSS identification. It is shown that there exists a simple algorit...

This paper describes a new object-oriented model and query algebra that will be used as an input language for the query optimizers that are being built as a part of the EREQ project. The model adopts a uniform view of objects and values and separates syntactic, semantic, and implementation concerns. The algebra addresses issues of type-defined equality and duplicate elimination as well as extensions to bulk types other than sets. 1 Introduction Recently, a great deal of work has been done on the topic of object-oriented query algebras [27, 22, 11] and the modeling of bulk types [4, 25, 19]. These proposals as well as those of other researchers on the topic have explored some of the fundamental issues and provided the starting point for the work reported here. AQUA (A QUery Algebra) is the result of a joint effort among researchers who have participated in the design of previous algebras [26, 30, 31]. AQUA has been designed to address a number of detailed modeling issues that we beli...

Coral++ is a database programming language that integrates Coral [23] with the C++ type system. The data model allows arbitrary C++ objects in database facts, and the declarative query language extends Coral with C++ expressions in rules. Coral++ also supports an imperative rule-based sub-language that is integrated with C++, providing support for updates. The design and implementation of Coral++ incorporates several important decisions: the data model is based on C++, and class definitions and method invocations are handled entirely by the C++ compiler; the notion of classes is kept orthogonal to the re-*The work of Haghu Hamakrishnan, Divesh Srivastava and Praveen Seshadri was supported by a David and Lutile