Graefe, G.: Volcano, an Extensible and Parallel Query Evaluation System, University of Colorado at Boulder, Technical Report No. 481, 1990.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....originating from both the properties inherent in the underlying data model or query language and the processing characteristics of the (potential) applications. 1) Extensibility: To satisfy specific needs of advanced applications, extensibility must be supported at different levels [11] [12] [13] To cope with later extensions either of the query language (e.g. due to new requirements arising from advanced applications) or of evaluation methods (such as improved join algorithms) a plan operator concept must exhibit flexibility and follow a modular design that clearly separates the ....

....To this end, we see plan operators as functional units accepting one or more input streams and producing exactly one result stream. The input is read and processed until it is exhausted. Thus, the plan operators follow an open next close paradigm to be found in many query processing systems, e.g. [12]. Extensibility at the Plan Operator Level As already pointed out in the introduction, extensibility must be supported at different levels to meet the specific requirements of advanced applications. Extensibility, in the context of plan operators, means providing new evaluation strategies for ....

[Article contains additional citation context not shown here]

Graefe, G.: Volcano, an Extensible and Parallel Query Evaluation System, University of Colorado at Boulder, Technical Report No. 481, 1990.

....results at each step and thus is not ideal when those intermediate results are large. The second method is a pipelining method and is used by most of the commercial systems such as Ingres [Sto80] and System R [CAB 81] and research projects such as Starburst [HCL 90] and Volcano [Gra94] A more thorough survey can be found in [Gra94] In this method, each operator supports an open next close interface, where open( does most of the preparation work and close( cleans up everything. In the next( calls, the operator simply generates one tuple result and then passes it to the ....

....when those intermediate results are large. The second method is a pipelining method and is used by most of the commercial systems such as Ingres [Sto80] and System R [CAB 81] and research projects such as Starburst [HCL 90] and Volcano [Gra94] A more thorough survey can be found in [Gra94] In this method, each operator supports an open next close interface, where open( does most of the preparation work and close( cleans up everything. In the next( calls, the operator simply generates one tuple result and then passes it to the operator above it in the tree. Pipelining requires ....

Goetz Graefe. Volcano, an extensible and parallel query evaluation system. IEEE Transactions on knowledge and data enginnering, 6(6):934--944, 1994.

.... 3 Optimization of a parallel match operator Relational binary operations are based on the matching of the tuples of two relations with respect to various criterions (identity of an attribute (equijoin) identity of all the attributes (intersection, difference) Following Graefe [11], we propose to integrate all the binary operators into a single framework, i.e. we consider that all those operators are only slightly different versions a same match operator. However, in contrast with the Volcano prototype [11] which does not include any optimization strategy for this match ....

....the attributes (intersection, difference) Following Graefe [11] we propose to integrate all the binary operators into a single framework, i.e. we consider that all those operators are only slightly different versions a same match operator. However, in contrast with the Volcano prototype [11] which does not include any optimization strategy for this match operator 5 , our optimization 5 In Volcano, the whole parallelization of the match operator is implemented by an external operator, called exchange, whose job is to distribute the data and trigger the execution, not to evaluate an ....

G.Graefe, Volcano, An extensible and parallel query evaluation system, IEEE trans. on Knowledge and Data Eng., No 6(1), 1994

....CA 94065, USA difficult to change. Customizability of such optimizers is almost impossible without an enormous effort by the database implementor (DBI) This difficulty has lead to the development of rule based query optimizers, whose primary purpose is to achieve query optimizer extensibility [9, 10, 12, 13]. The basic idea is that the actions of a query optimizer are defined as a set of rewrite rules that progressively optimize expressions which define how queries can be evaluated. From our experience, the rule sets of such optimizers are rather brittle. If a new feature (e.g. retrieval or join ....

....how queries can be evaluated. From our experience, the rule sets of such optimizers are rather brittle. If a new feature (e.g. retrieval or join algorithm) is to be added to an optimizer, it is not quite a simple matter of adding one or more rules. For example, in the Volcano rule based optimizer [10], rule implementations are not encapsulated. Consequently, conceptually simple modifications to a rule set often require significant effort including new function definitions to characterize the new feature. Modifying rule sets is actually quite important for systems like Starburst [15] Open OODB ....

[Article contains additional citation context not shown here]

Goetz Graefe. Volcano, an extensible and parallel query evaluation system. Technical Report CU--CS--481--90, University of Colorado at Boulder, July 1990.

....it to an algebraic query, then, after manipulating the algebraic query in different ways, transforms that to an access plan in a language for object access. Almost all query optimizers (extensible or not) process a query through some fixed sequence of optimization stages (e.g. 45] 54] [56], 64] 129] 130] 142] 152] An Epoq optimizer can simulate this kind of sequential processing in a straightforward way. For example, each stage of processing could be represented by a separate region, with a single level of control over those regions responsible for executing them in the ....

....other optimizers The main difference between the Epoq approach to optimization and other approaches for extensible or object oriented optimization systems is that Epoq provides for extensibility of the optimization process itself. As noted earlier, most extensible optimizers (e.g. 45] 54] [56], 64] 140] provide a fixed strategy for searching for and applying rules for query transformation. In other words, although the possible optimizer results can be extended, the optimization process itself is fixed. This is analogous to the single flashlight picture in the introduction to this ....

Goetz Graefe. Volcano, an Extensible and Parallel Query Evaluation System. Technical Report CU-CS-481-90, University of Colorado at Boulder, July 1990.

....there are duplicates in the outer references. Our invariant technique is useful whether there are duplicates or not, although we can get additional benefit from memoization when there are duplicates in the outer references. We will base our discussion on the Volcano style query execution engine [Gra94] in which each query plan is a tree of operators. All operators are implemented as iterators and support a simple open nextclose interface, where open( does most of the preparation work, next( fetches the rows one by one and close( cleans up everything. Most relational database systems have ....

Goetz Graefe. Volcano, an extensible and parallel query evaluation system. IEEE Transactions on knowledge and data enginnering, 6(6):934--944, 1994.

....tree structured query plan. The request manager then register the query plan with the scheduler. The activation of a query plan usually involves the request manager, the resource manager, and the scheduler. Query execution in XPS follows the iterator model that is similar to that of the Volcano [Gra90]. The iterator model in XPS follows a simple create open next close free protocol. Basically, iterators go through the following stages: creation, initialization, iteration (loop through the input data set by calling next) termination, and free(deletion) The iterator model has the following ....

Goetz Graefe. Volcano, an Extensible and Parallel Query Evaluation System. Technical Report CU-CS-481-90, University of Colorado at Boulder, 1990.

.... database systems, and in turn extensible optimizers, has long been recognized in systems like Genesis [1] EXODUS [9] Starburst [10] and Postgres [12] Rule based query optimizers are among the major conceptual advances that have been proposed to deal with query optimizer extensibility [6, 7, 9, 10]. The extensibility translates into the ability to incorporate new operators, algorithms, cost models, or search strategies without changing the optimization algorithm. In this paper, we describe an algebraic framework called Prairie for specifying rules in a rule based query optimizer. Prairie ....

....cost models, or search strategies without changing the optimization algorithm. In this paper, we describe an algebraic framework called Prairie for specifying rules in a rule based query optimizer. Prairie is similar to other rule specification languages like Starburst [10] and Volcano [7], and indeed, we have based our work on Volcano to capture most of the advantages of rule based optimizers. However, Prairie attempts to provide some key features that, we have found, simplify the effort in writing rules: 1. A framework in which users can define a query optimizer concisely in ....

[Article contains additional citation context not shown here]

Goetz Graefe. Volcano, an extensible and parallel query evaluation system. Technical Report CU--CS-- 481--90, University of Colorado at Boulder, July 1990.

....1 the leaf regions are shown simply as transformations. Of course, these transformations will, in practice, be complicated strategies for manipulating queries. The control presented here concentrates on the integration of transformation strategies. Most extensible optimizers (e.g. 5] 7] [8], 10] 20] provide a fixed control over the application of strategies to manipulate queries. This makes it difficult for these optimizers to adapt to a changing repertoire of strategies. Epoq allows extension of the control as well as the addition of new optimization strategies. Epoq was ....

....in nested transactions to later work. 6 Related Work The main difference between the Epoq approach to optimization and other approaches for extensible or objectoriented systems is that Epoq provides for extensibility of the optimization process itself. Most extensible optimizers (e.g. 5] 7] [8], 10] 20] provide a fixed strategy for searching for and applying rules for query transformation. In other words, although the possible optimizer results can be extended, the optimization process is fixed. Proposals for object oriented optimizers either use one of these extensible approaches ....

Goetz Graefe. Volcano, an Extensible and Parallel Query Evaluation System. Technical Report CU-CS481 -90, University of Colorado at Boulder, July 1990.

.... extensible database systems, and in turn extensible optimizers, has long been recognized in systems like Genesis [1] EXODUS [3] Starburst [15] and Postgres [18] Rule based query optimizers are among the major conceptual advances that have been proposed to deal with query optimizer extensibility [6 8, 10, 11, 13]. The extensibility translates into the ability to incorporate new operators, algorithms, cost models, or search strategies without changing the optimization algorithm. In this paper, we describe an algebraic framework called Prairie for specifying rules in a query optimizer. Prairie is similar to ....

....operators, algorithms, cost models, or search strategies without changing the optimization algorithm. In this paper, we describe an algebraic framework called Prairie for specifying rules in a query optimizer. Prairie is similar to other rule specification languages like Starburst [13] and Volcano [8], and indeed, we have based our work on Volcano to capture most of the advantages of rule based optimizers. However, Prairie attempts to provide some key features that, we have found, simplify the effort in writing rules: 1. A framework in which users can define a query optimizer concisely in ....

[Article contains additional citation context not shown here]

Goetz Graefe. Volcano, an extensible and parallel query evaluation system. Technical Report CU--CS--481--90, University of Colorado at Boulder, July 1990.

No context found.

Gr94 Graefe, G.: Volcano, an Extensible and Parallel Query Evaluation System, IEEE Trans. Knowledge and Data Engineering 6:1, 1994, 120-135.

No context found.

G. Graefe. Volcano, An extensible and parallel query evaluation system. IEEE trans. on Knowledge and Data Engineering, No 6(1), 1994.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC