G. Graefe and D. J. DeWitt. The Exodus Optimizer Generator. In Proceedings of ACM SIGMOD, pp. 160--172 (1987).  Home/Search   Document Details and Download   Summary   Related Articles   Check

....a rule based query optimizer which unlike the GemStone system makes the exploitation of existing access support relations entirely transparent to the database user. Rule based query optimization is not an entirely new idea: it is borrowed from relational query optimization, e.g. 5, 8, 13, 14] [6] reports on a rule based query opti mizer generator, which was designed for their database generator EXODUS [2] In the present work the idea of rule based query optimization is utilized as a power ful tool to integrate the new index structure based on access support relations in object oriented ....

G. Graefe and D. DeWitt. The EXODUS optimizer generator. In Proc. of the ACM SIGMOD Conf. on Management of Data, pages 160-172, San Francisco, 1987.

....concerning the support for multiple equivalence types, as well as selectivity estimation and the staged optimization strategy (see Section 4) In the rest of this section, we consider the existing extensible query optimizers that are related to Volcano. Volcano evolved from the Exodus optimizer [GW87], which in [CW96] was found to be very general, but inefficient, hard to use, and requiring a lot of additional implementation code from the optimizer implementor. Volcano contributed an efficient search strategy, as well as better abstractions for costs and properties. The Cascades optimization ....

G. Graefe and D. J. DeWitt. The Exodus Optimizer Generator. In Proceedings of ACM SIGMOD, San Francisco, CA, pp. 160--172 (1987).

....a query optimizer makes it one of the most complex components to write in a DBMS. In the past, query optimizers mainly relational ones [25, 1] followed a black box approach. The optimizer knowledge was procedural making it difficult to evolve. Recently, extensible optimizers have been proposed [12, 13, 22]. The key idea was to generate a query optimizer from rules for transforming plans into alternative plans. Many rule languages have been proposed: term rewriting, functional or algebra equivalences. To control The work reported here was partially supported by Slovak Science Grant Agency, No. ....

G. Graefe, D. DeWitt. The EXODUS Optimizer Generator. Ph.D. Thesis, University of Wisconsin, August 1987.

....a xed search strategy is always a rulebased system. It often implements a rule rewriter to perform equivalent transformation on the query expressions. Representatives of this kind of system include: the System R style Optimizer [15] Starburst project [16] 31] the Exodus Optimizer Generator [7], and the Volcano Optimizer Generator [8] The system R style Optimizer designs sets of rules to translate a query into a physical plan. One set of them is to convert the query into an algebraic tree. Other sets are used to generate access paths, join orders, and join methods. The optimizer ....

G. Graefe and D.J. DeWitt. The EXODUS Optimizer Generator. Proceedings of the 1987.

....to sequence and prune the search space. 5.2.2.3.1 Rewrite System The search space is defined by the space of algebraic rewrites presented in the rewrite system. Like the previous generation of rule based optimizers, the rewrite system in the Venus based optimizer is implemented in rule based form [32,47,48,80]. The rewrite system applies different transformation and implementation rewrites on a subquery by exploiting procedural and heuristic elements, constrained by the algebraic representation. If the preconditions and conditions for a rewrite are satisfied, the operator is applied and the new ....

G. Graefe and D. J. Dewitt, "The EXODUS optimizer generator," in Proceedings,

....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 ....

....of the algebra level, the plan level or the code generation as little as possible. Thus, extensibility may for example comprise enhancing the semantics of inheritance or including new, system defined relationships and their semantics into the user interface of KRISYS. Unlike EXODUS or Volcano [11] [12] we do not want to generate a new optimizer for each dialect that comes into existence by extending KOALA, nor do we aim at extensibility of the datamanagement facilities, as done in Starburst [13] 3.2 Operational Requirements Efficiency of Dynamic Query Optimization Knowledge processing ....

Graefe, G, DeWitt, D.: The EXODUS Optimizer Generator, Proc.

....For example, adding a new operator, such as aggregation, required myriad changes to the optimizer. Approximately ten years ago, researchers proposed two ways to build extensible optimizers. Lohman [Loh88] proposed using rules to generate plans in a bottom up optimizer; Graefe and DeWitt [GrD87] proposed using transforms (the topdown version of rules) to generate new plans using a topdown approach. Lohmans generative rules were implemented in Starburst[HCL90] Several Starburst projects have demonstrated Starbursts extensibility, from incremental joins [CSL90] to distributed ....

....and if it is not effective, they reoptimize. Our upper bounds are based on previously constructed plans rather than externally determined thresholds. Furthermore, our upper bounds can differ for each subplan being optimized. Top down optimization began with the Exodus optimizer generator [GrD87], whose primary purpose was to demonstrate extensibility. Graefe and collaborators subsequently developed Volcano [GrM93] with the primary goal of improving efficiency with memoization. Volcanos efficiency was hampered by its search strategy, which generated all logical expressions before ....

G. Graefe and D. J. DeWitt, The EXODUS Optimizer Generator, Proc. SIGMOD 1987, Pg. 160-172.

....is allowed, thus leading to query nesting in SELECT, FROM (cf. Example 3.3) and WHERE clauses. Some nested MAD queries can be transformed into equivalent MAD statements with a lower degree of nesting (statement simplification, Example 3. 3) based on well known strategies, as described in [21,13]. Qualified projection is supplied to select components by their values rather than by their types. Qualifications on whole molecules are normally expressed using the WHERE clause. Thus, qualified projection concerning the root atom type can be equivalently transformed into a qualification ....

G. Graefe and D.J. DeWitt, The EXODUS Optimizer Generator, in: Proc. ACM SIGMOD Int. Conf. on Management of Data, San Francisco (1987) 160-172.

....in part by ESPRIT III project 7091, Pythagoras . y C. Galindo Legaria was supported by an ERCIM fellowship. 1 Several probabilistic search strategies have been proposed, like : Simulated Annealing (SA) Iterative Improvement (II) and others [IW87, IK90, IK91, SG88, LVZ93, OL90, INSS92, GD87] These search strategies are probabilistic in the sense that they start at a randomly selected QEP and or the generation of the next QEP involves some probability. To generate the next QEP transformation rules are used. These rules are based on properties of the underlying algebra, such ....

G. Graefe and D. J. DeWitt. The exodus optimizer generator. Proc. of the ACM-SIGMOD Conference on Management of Data, pages 160--172, 1987.

....TPC H queries in Section 5. Section 6 concludes the paper. 2. Preliminaries In this section we review the concept of a compact representation of the plan space in form of the MEMO structure. This concept was developed by Graefe and DeWitt in the context of transformation based query optimization [4, 5, 1]. Independent of this development, a similar structure has been developed for bottom up enumeration of join trees in Starburst [8] Our technique is based on the MEMO but could be transferred easily to the Starburst enumerator. We will briefly introduce the essential aspects of the MEMO and refer ....

G. Graefe and D. J. DeWitt. The EXODUS Optimizer Generator. In Proc. of the ACM SIGMOD Int'l. Conf. on Management of Data, San Francisco, CA, USA, May 1987.

....two different plans, one of which has greater parallelism while the other consumes less resources. We feel that optimizers are becoming exceedingly complex, and we have pointed out that main memory and parallelism considerations will necessarily result in additional complexity. Although others [GRAE87, LOHM88] are trying to make optimizers extendible, we are more concerned with making them simpler so that additional optimization, such as that discussed above, can be performed. To accomplish this goal, we plan to restrict the collection of available join tactics. All optimizers must include iterative ....

Graefe, G. and Dewitt, D., "The EXODUS Optimizer Generator," Proc. 1987 ACM-SIGMOD Conference on Management of Data, San Francisco, CA, May 1987.

....bottom up plan enumeration, we annotate each (sub )plan with properties. 8 Plan properties are also used for pruning plans during the bottom up plan enumeration. For brevity, we will not present the details of pruning here. Annotating plans is also done in traditional query optimizers ( GD87, Loh88] Typical plan properties include the cost of a plan, the cardinality of the output produced by the plan, or the site at which the plan is executed in a distributed system. To integrate early sorting and early partitioning, the following properties are relevant: sorted by: a set of ....

G. Graefe and D. DeWitt. The EXODUS optimizer generator. In Proc. of the ACM SIGMOD Conf. on Management of Data, pages 160--172, San Francisco, CA, USA, May 1987.

....specifications with queries. The bottom layer contains the implementations of the logical expressions. Object names are mapped to object identifiers which behave similar to virtual memory addresses. The basic optimization techniques at this level are rewritings of algebraic expressions (e.g. [FREY87,GD87]) and redundant data, esp. indices (e.g. KM90a] An integrated trigger mechanism at the implementation layer meets the requirements for active database systems whose active components enable the creation and execution of data manipulation operations in a production rule like way. In our view ....

Graefe,G., DeWitt,D.J. (1987). The EXODUS optimizer generator. Proc. ACM-SIGMOD 1987.

....the result of a predicate, the estimated cost of verifying a predicate, and the physical location of the data sets so that the transfer of data between various sites is minimized. Query processing in logic databases [Bancilhon 1986] Sagiv 1988] and rule based query optimization [Freytag 1987] [Graefe 1987] are ongoing research topics. 6 Drawbacks of a Prolog Based Query Language Prolog was designed to express logical relations in a short lived environment where users are aware of all facts and rules stored. Facts and rules are stored in files and users recall them explicitly when they need them. ....

G. Graefe and D. DeWitt. The EXODUS Optimizer Generator. In: SIG-MOD Conference, pages 160-171, San Francisco, CA, May 1987.

....Maier , Paul Benninghoff , Keith Billings , Yubo Fan , Kavita Hatwal , Bennet Vance , Quan Wang Abstract System R s bottom up query optimizer architecture[SAC 79] forms the basis of most current commercial database managers. This paper compares the performance of a top down architecture [GrD87] to a bottom up architecture, as measured by the number of plans generated during optimization. We claim that on this dimension, top down optimizers are superior because top down optimizers can use upper and lower bounds to avoid generating groups of plans. Early during the optimization of a ....

....For example, adding a new operator, such as aggregation, required myriad changes to the optimizer. Approximately ten years ago, researchers proposed two ways to build extensible optimizers. Lohman [Loh88] proposed using rules to generate plans in a bottom up optimizer; Graefe and DeWitt [GrD87] proposed using transforms (the top down version of rules) to generate new plans using a top down approach. Lohman s generative rules were implemented in Starburst[HCL90] Several Starburst projects have demonstrated Starburst s extensibility, from incremental joins [CSL90] to distributed ....

[Article contains additional citation context not shown here]

G. Graefe and D. J. DeWitt, The EXODUS Optimizer Generator, Proc. SIGMOD 1987, Pg. 160172.

....Also, the choice of the primary ## predicate (key or RID) can impact the choice of the ## method and order. Being aware of all these options, it is quite straightforward to extend an existing optimizer to make these decisions; for example, a query optimizer based on dynamic programming [4, 12] can easily be extended for this purpose. We will present and discuss the tradeoffs of three viable plans in the next subsection. 2.2. Examples To demonstrate alternative ways to execute bulk deletes, we will go back to the example of the introduction. Table R from which records are supposed to ....

G. Graefe and D. DeWitt. The EXODUS optimizer generator. In Proc. of the ACM SIGMOD Conf. on Management of Data, pages 160--172, San Francisco, CA, USA, May 1987.

.... on query algebras, the generator paradigm (data model specification as input data) separation of logical and physical algebras, separation of logical and physical properties, extensive use of algebraic rules (transformation rules and implementation rules) and its focus on software modularization [Gra87, GrD87]. Considering the complexity of typical query optimization software and the importance of welldefined modules to conquer the complexities of software design and maintenance, the latter two points might well be the most important contributions of the EXODUS optimizer generator research. The ....

....aborted due to lack of memory or was aborted because it ran much longer than the Volcano optimizer generator.Furthermore, we observed in repeated experiments that the EXODUS optimizer generator measurements were quite volatile. Similar problems were observed in EXODUS experiments reported in [GrD87]. The Volcano generated optimizer performed exhaustive search for all queries with less than 1MBofwork space. The data points in Figure 4 represent only those queries for which the EXODUS optimizer generator completed the optimization. The search times reflect Volcano smore efficient search ....

G. Graefe and D. J. DeWitt, The EXODUS Optimizer Generator, Proc. ACM SIGMOD Conf.,San Francisco, CA, May 1987, 160.

.... and hard to augment with search heuristics (which are very important for query optimization) 25 Based on this limitation, and also on further considerations such as call compatibility with other EXODUS components and optimizer execution speed, we decided instead to provide an optimizer generator [Grae86] which produces an optimization procedure in the programming language C [Kern78] The generated optimization procedure takes a query as its input, producing an access plan as its output. A query in this context is a tree like expression with logical operators as internal nodes (e.g. a join in a ....

Graefe, G. and D. DeWitt, "The EXODUS Optimizer Generator," submitted for publication, December, 1986.

....system software. The implementation of some DBMS components is supported by tools which actually generate the components from specifications; for example, tools are provided to generate a query optimizer from a rule based description of a data model, its operators, and their implementations [Graefe and DeWitt 1987]. Other components, such as new abstract data types, access methods, and database operations, must be explicitly coded by the DBI due to their more widely varying and highly algorithmic nature. 1 EXODUS attempts to simplify this aspect of the DBI s job by providing a programming language with ....

Graefe, G. and D. DeWitt, "The EXODUS Optimizer Generator," Proceedings of the 1987 SIGMOD Conference, San Francisco, CA, May 1987.

No context found.

G. Graefe and D. J. DeWitt. The Exodus Optimizer Generator. In Proceedings of ACM SIGMOD, pp. 160--172 (1987).

No context found.

G. Graefe and D. DeWitt. The EXODUS optimizer generator. In Proc. of the ACM SIGMOD Conf. on Management of Data, pages 160--172, San Francisco, 1987.

No context found.

Goetz Graefe and David J. DeWitt. The exodus optimizer generator. In Umeshwar Dayal and Irving L. Traiger, editors, Proceedings of the Association for Computing Machinery Special Interest Group on Management of Data 1987.

No context found.

Goetz Graefe and D. DeWitt. The EXODUS Optimizer Generator. In ACM SIGMOD Conference, 1987.

No context found.

G. Graefe and D.J. DeWitt. The EXODUS Optimizer Generator. In Proc. ACM SIGMOD Conference, pp. 160--172, San Francisco, 1987.

No context found.

G. Graefe and D. DeWitt. The EXODUS optimizer generator. In ACM SIGMOD Conf., San Francisco, 1987.

First 50 documents  Next 50

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