Database management systems will continue to manage large data volumes. Thus, efficient algorithms for accessing and manipulating large sets and sequences will be required to provide acceptable performance. The advent of object-oriented and extensible database systems will not solve this problem. On the contrary, modern data models exacerbate it: In order to manipulate large sets of complex objects as efficiently as today's database systems manipulate simple records, query processing algorithms and software will become more complex, and a solid understanding of algorithm and architectural issues is essential for the designer of database management software.This survey provides a foundation for the design and implementation of query execution facilities in new database management systems. It describes a wide array of practical query evaluation techniques for both relational and post-relational database systems, including iterative execution of complex query evaluation plans, the duality of sort-and hash-based set matching algorithms, types of parallel query execution and their implementation, and special operators for emerging database application domains.

Abstract

To investigate the interactions of extensibility and parallelism in database query processing, we have developed a new dataflow query execution system called Volcano. The Volcano effort provides a rich environment for research and education in database systems design, heuristics for query optimization, parallel query execution, and resource allocation. Volcano uses a standard interface between algebra operators, allowing easy addition of new operators and operator implementations. Operations on individual items, e.g., predicates, are imported into the query processing operators using support functions. The semantics of support functions is not prescribed; any data type including complex objects and any operation can be realized. Thus, Volcano is extensible with new operators, algorithms, data types, and type-specific methods. Volcano includes two novel meta-operators. The choose-plan meta-operator supports dynamic query evaluation plans that allow delaying selected optimization decisions until run-time, e.g., for embedded queries with free variables. The exchange meta-operator supports intra-operator parallelism on partitioned datasets and both vertical and horizontal inter-operator parallelism, translating between demand-driven dataflow within processes and data-driven dataflow between processes. All operators, with the exception of the exchange operator, have been designed and implemented in a single-process environment, and parallelized using the exchange operator. Even operators not yet designed can be parallelized using this new operator if they use and provide the interator interface. Thus, the issues of data manipulation and parallelism have become orthogonal, making Volcano the first implemented query execution engine that effectively combines extensibility and parallelism. Index Terms-Dynamic query evaluation plans, extensible database systems, iterators, operator model of parallelization, query execution. Gnetz Graefe was an undergraduate student in business administration and computer science in Germany before getting his M.S. and Ph.D. degree in computer science in 1984 and 1987, respectively. from the University of Wisconsin-Madison. His dissertation work was on the EX-ODUS Optimizer Generator under David DeWitt and Michael Carey. In 1987, he joined the faculty of the Oregon Graduate Institute, where he initiated both the Volcano project and with David Maier, the REVELATION OODBMS project. From 1989 to 1992, he was with the University of Colorado at Boulder. Since 1992. he has been an Associate Professor with Portland State Unlversity. He is currently working on extensions to Volcano, including a new optimizer generator. on request processing in OODBMS's and scientific databases, and on physical database design.

No abstract

This technical note shows how to combine some well-known techniques to create a method that will efficiently execute common multi-table joins. We concentrate on a commonly occurring type of join known as a star-join, although the method presented will generalize to any type of multi-