A history and evaluation of System R

Chamberlin, Donald D.; Astrahan, M. M.; Blasgen, M. W.; Gray, Jim; King, William F.; Lindsay, Bruce G.; Lorie, Raymond A.; Mehl, J. W.; Price, Thomas G.; Putzolu, Franco; Selinger, Patricia G.; Schkolnick, Mario; Slutz, D. R.; Traiger, I. L.; Wade, B. W.; Yost, Robert A.

doi:10.1145/358769.358784

Cited by 198 publications

(58 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Historically, System R [2] first proposed code generation for query optimization. However, the Volcano iterator model eventually dominated over compilation, since code generation was very expensive to maintain.…”

Section: Related Workmentioning

confidence: 99%

Building efficient query engines in a high-level language

et al. 2014

View full text Add to dashboard Cite

In this paper we advocate that it is time for a radical rethinking of database systems design. Developers should be able to leverage high-level programming languages without having to pay a price in efficiency. To realize our vision of abstraction without regret, we present LegoBase, a query engine written in the high-level programming language Scala. The key technique to regain efficiency is to apply generative programming: the Scala code that constitutes the query engine, despite its high-level appearance, is actually a program generator that emits specialized, low-level C code. We show how the combination of high-level and generative programming allows to easily implement a wide spectrum of optimizations that are difficult to achieve with existing low-level query compilers, and how it can continuously optimize the query engine.We evaluate our approach with the TPC-H benchmark and show that: (a) with all optimizations enabled, our architecture significantly outperforms a commercial in-memory database system as well as an existing query compiler, (b) these performance improvements require programming just a few hundred lines of high-level code instead of complicated low-level code that is required by existing query compilers and, finally, that (c) the compilation overhead is low compared to the overall execution time, thus making our approach usable in practice for efficiently compiling query engines.

show abstract

Section: Related Workmentioning

confidence: 99%

Building efficient query engines in a high-level language

et al. 2014

View full text Add to dashboard Cite

show abstract

“…Code generation techniques for DBMS go back to System R [11]. Recently, code generation has been realized using highly efficient code templates and dynamically instantiating them to create query-and hardware-specific code [21].…”

Section: Related Workmentioning

confidence: 99%

Adaptive query processing on RAW data

et al. 2014

View full text Add to dashboard Cite

Database systems deliver impressive performance for large classes of workloads as the result of decades of research into optimizing database engines. High performance, however, is achieved at the cost of versatility. In particular, database systems only operate efficiently over loaded data, i.e., data converted from its original raw format into the system's internal data format. At the same time, data volume continues to increase exponentially and data varies increasingly, with an escalating number of new formats. The consequence is a growing impedance mismatch between the original structures holding the data in the raw files and the structures used by query engines for efficient processing. In an ideal scenario, the query engine would seamlessly adapt itself to the data and ensure efficient query processing regardless of the input data formats, optimizing itself to each instance of a file and of a query by leveraging information available at query time. Today's systems, however, force data to adapt to the query engine during data loading. This paper proposes adapting the query engine to the formats of raw data. It presents RAW, a prototype query engine which enables querying heterogeneous data sources transparently. RAW employs Just-In-Time access paths, which efficiently couple heterogeneous raw files to the query engine and reduce the overheads of traditional general-purpose scan operators. There are, however, inherent overheads with accessing raw data directly that cannot be eliminated, such as converting the raw values. Therefore, RAW also uses column shreds, ensuring that we pay these costs only for the subsets of raw data strictly needed by a query. We use RAW in a real-world scenario and achieve a two-order of magnitude speedup against the existing hand-written solution.

show abstract

“…Aggregation is supported in IMS by permitting hierarchical segments in the same data set; in network systems, by storing MEMBER record types in the OWNER area using VIA SET and NEAR OWNER commands in the schema. Relational systems do not allow aggregator at a logical level; however, substantial efficiencies are achieved by its use at the physical level [4,8]. In fact, many relational systems are now beginning to support clustering (e.g.…”

Section: The Generic Physical Design Modelmentioning

confidence: 99%

Sensitivity of the physical database design to changes in underlying factors

Palvia

1988

Information & Management

View full text Add to dashboard Cite

Abstract:Several articles have reported on the optimization of the complete physical database design or significant parts of it. However, few results are available on the sensitivity of the physical database design to change in underlying factors that influence the design decisions. Such tenths would be of significant practical value in both the design of the initial physical database and its subsequent restructuring. This paper considers underlying factors related to logical data structure, queries, computer system and physical implementation. An experimental design based on these factors is developed and experiments are conducted to determine the sensitivity effects, and these are reported and discussed. Keywords: Database, Database design, Physical database, Initial database design, Database restructurings, Database monitoring, Sensitivity analysis, Performance evaluation, Optimization, Input-output analysis Article:1. Introduction Sensitivity analysis refers to change in outputs or the final optimal solution due to changes in inputs. It has been applied in many complex settings in different business areas, e.g., in accounting [13], financial management and capital budgeting [12,21], and manufacturing [20). Currently, many computerized tools, such as IFPS [14] and LOTUS [17], facilitate the process of conducting this kind of "what-if" analysis. In addition, operations research has produced formal methods for conducting sensitivity analysis in special cases (e.g., linear programming problems occurring in manufacturing, resource allocation, and scheduling and in inventory management problems [10]). Here we consider the sensitivity of the physical database design to underlying variables. Results were obtained by conducting controlled experiments in a laboratory setting.The design of physical databases is a complex activity. Many researchers have proposed methods to optimize either specific sub-problems in this area [9,11.18,19] or to optimize the entire problem in different contexts [3,6,7,15,16,22,23,24]. They consider many factors simultaneously in the design process. Research/experience does not generally provide information on the sensitivity of the physical database design to the underlying factors. Such results are of significant practical both at initial design and redesign. During the initial design (especially in the absence of optimization tools), the designer is aided in the knowledge of the relative importance of the various factors. This knowledge also helps at redesign time, because the designer is constantly faced with restructuring the physical database due to changing user and technical requirements.What is meant by sensitivity analysis? As the design factors change, both the optimal physical database design itself and the operational cost of using the design may change; indeed the cost will almost always change. However, our main concern in this sensitivity analysis is to study the relative changes in the optimal physical database design. Objectives and Underlying Factors in Physical Database ...

show abstract

A history and evaluation of System R

Cited by 198 publications

References 29 publications

Building efficient query engines in a high-level language

Building efficient query engines in a high-level language

Adaptive query processing on RAW data

Sensitivity of the physical database design to changes in underlying factors

Contact Info

Product

Resources

About