Martin Utesch University of Mining and Technology Institute of Automatic Control

Freiberg Germany

1997-10-02 Written by Martin Utesch (utesch@aut.tu-freiberg.de) for the Institute of Automatic Control at the University of Mining and Technology in Freiberg, Germany. Among all relational operators the most difficult one to process and optimize is the join. The number of alternative plans to answer a query grows exponentially with the number of joins included in it. Further optimization effort is caused by the support of a variety of join methods (e.g., nested loop, hash join, merge join in PostgreSQL) to process individual joins and a diversity of indexes (e.g., R-tree, B-tree, hash in PostgreSQL) as access paths for relations. The current PostgreSQL optimizer implementation performs a near-exhaustive search over the space of alternative strategies. This algorithm, first introduced in the System R database, produces a near-optimal join order, but can take an enormous amount of time and memory space when the number of joins in the query grows large. This makes the ordinary PostgreSQL query optimizer inappropriate for queries that join a large number of tables. The Institute of Automatic Control at the University of Mining and Technology, in Freiberg, Germany, encountered the described problems as its folks wanted to take the PostgreSQL DBMS as the backend for a decision support knowledge based system for the maintenance of an electrical power grid. The DBMS needed to handle large join queries for the inference machine of the knowledge based system. Performance difficulties in exploring the space of possible query plans created the demand for a new optimization technique to be developed. In the following we describe the implementation of a Genetic Algorithm to solve the join ordering problem in a manner that is efficient for queries involving large numbers of joins. The genetic algorithm (GA) is a heuristic optimization method which operates through nondeterministic, randomized search. The set of possible solutions for the optimization problem is considered as a population of individuals. The degree of adaptation of an individual to its environment is specified by its fitness. The coordinates of an individual in the search space are represented by chromosomes, in essence a set of character strings. A gene is a subsection of a chromosome which encodes the value of a single parameter being optimized. Typical encodings for a gene could be binary or integer. Through simulation of the evolutionary operations recombination, mutation, and selection new generations of search points are found that show a higher average fitness than their ancestors. According to the comp.ai.genetic FAQ it cannot be stressed too strongly that a GA is not a pure random search for a solution to a problem. A GA uses stochastic processes, but the result is distinctly non-random (better than random).

P(t) generation of ancestors at a time t P''(t) generation of descendants at a time t +=========================================+ |>>>>>>>>>>> Algorithm GA <<<<<<<<<<<<<<| +=========================================+ | INITIALIZE t := 0 | +=========================================+ | INITIALIZE P(t) | +=========================================+ | evaluate FITNESS of P(t) | +=========================================+ | while not STOPPING CRITERION do | | +-------------------------------------+ | | P'(t) := RECOMBINATION{P(t)} | | +-------------------------------------+ | | P''(t) := MUTATION{P'(t)} | | +-------------------------------------+ | | P(t+1) := SELECTION{P''(t) + P(t)} | | +-------------------------------------+ | | evaluate FITNESS of P''(t) | | +-------------------------------------+ | | t := t + 1 | +===+=====================================+

The GEQO module approaches the query optimization problem as though it were the well-known traveling salesman problem (TSP). Possible query plans are encoded as integer strings. Each string represents the join order from one relation of the query to the next. For example, the join tree /\ /\ 2 /\ 3 4 1 is encoded by the integer string '4-1-3-2', which means, first join relation '4' and '1', then '3', and then '2', where 1, 2, 3, 4 are relation IDs within the PostgreSQL optimizer. Parts of the GEQO module are adapted from D. Whitley's Genitor algorithm. Specific characteristics of the GEQO implementation in PostgreSQL are: Usage of a steady state GA (replacement of the least fit individuals in a population, not whole-generational replacement) allows fast convergence towards improved query plans. This is essential for query handling with reasonable time; Usage of edge recombination crossover which is especially suited to keep edge losses low for the solution of the TSP by means of a GA; Mutation as genetic operator is deprecated so that no repair mechanisms are needed to generate legal TSP tours. The GEQO module allows the PostgreSQL query optimizer to support large join queries effectively through non-exhaustive search. Work is still needed to improve the genetic algorithm parameter settings. In file src/backend/optimizer/geqo/geqo_main.c, routines gimme_pool_size and gimme_number_generations, we have to find a compromise for the parameter settings to satisfy two competing demands: Optimality of the query plan Computing time At a more basic level, it is not clear that solving query optimization with a GA algorithm designed for TSP is appropriate. In the TSP case, the cost associated with any substring (partial tour) is independent of the rest of the tour, but this is certainly not true for query optimization. Thus it is questionable whether edge recombination crossover is the most effective mutation procedure. The following resources contain additional information about genetic algorithms: The Hitch-Hiker's Guide to Evolutionary Computation (FAQ for comp.ai.genetic) Evolutionary Computation and its application to art and design by Craig Reynolds