granicus.if.org Git - postgresql/blob - doc/src/sgml/geqo.sgml

   1 <!--
   2 $Header: /cvsroot/pgsql/doc/src/sgml/geqo.sgml,v 1.9 2000/03/31 03:27:40 thomas Exp $
   3 Genetic Optimizer
   4 -->
   5
   6 <Chapter Id="geqo">
   7 <DocInfo>
   8 <Author>
   9 <FirstName>Martin</FirstName>
  10 <SurName>Utesch</SurName>
  11 <Affiliation>
  12 <Orgname>
  13 University of Mining and Technology
  14 </Orgname>
  15 <Orgdiv>
  16 Institute of Automatic Control
  17 </Orgdiv>
  18 <Address>
  19 <City>
  20 Freiberg
  21 </City>
  22 <Country>
  23 Germany
  24 </Country>
  25 </Address>
  26 </Affiliation>
  27 </Author>
  28 <Date>1997-10-02</Date>
  29 </DocInfo>
  30
  31 <Title>Genetic Query Optimization in Database Systems</Title>
  32
  33 <Para>
  34 <Note>
  35 <Title>Author</Title>
  36 <Para>
  37 Written by <ULink url="utesch@aut.tu-freiberg.de">Martin Utesch</ULink>
  38 for the Institute of Automatic Control at the University of Mining and Technology in Freiberg, Germany.
  39 </Para>
  40 </Note>
  41 </para>
  42
  43 <Sect1>
  44 <Title>Query Handling as a Complex Optimization Problem</Title>
  45
  46 <Para>
  47    Among all relational operators the most difficult one to process and
  48 optimize is the <FirstTerm>join</FirstTerm>. The number of alternative plans to answer a query
  49 grows exponentially with the number of <Command>join</Command>s included in it. Further
  50 optimization effort is caused by the support of a variety of <FirstTerm>join methods</FirstTerm>
  51  (e.g., nested loop, index scan, merge join in <ProductName>Postgres</ProductName>) to
  52 process individual <Command>join</Command>s and a diversity of <FirstTerm>indices</FirstTerm> (e.g., r-tree,
  53 b-tree, hash in <ProductName>Postgres</ProductName>) as access paths for relations.
  54 </para>
  55
  56 <Para>
  57    The current <ProductName>Postgres</ProductName> optimizer implementation performs a <FirstTerm>near-
  58 exhaustive search</FirstTerm> over the space of alternative strategies. This query
  59 optimization technique is inadequate to support database application
  60 domains that involve the need for extensive queries, such as artificial
  61 intelligence.
  62 </para>
  63
  64 <Para>
  65    The Institute of Automatic Control at the University of Mining and
  66 Technology, in Freiberg, Germany, encountered the described problems as its
  67 folks wanted to take the <ProductName>Postgres</ProductName> DBMS as the backend for a decision
  68 support knowledge based system for the maintenance of an electrical
  69 power grid. The DBMS needed to handle large <Command>join</Command> queries for the
  70 inference machine of the knowledge based system.
  71 </para>
  72
  73 <Para>
  74    Performance difficulties within exploring the space of possible query
  75 plans arose the demand for a new optimization technique being developed.
  76 </para>
  77
  78 <Para>
  79    In the following we propose the implementation of a <FirstTerm>Genetic Algorithm</FirstTerm>
  80  as an option for the database query optimization problem.
  81 </para>
  82 </sect1>
  83
  84 <Sect1>
  85 <Title>Genetic Algorithms (<Acronym>GA</Acronym>)</Title>
  86
  87 <Para>
  88    The <Acronym>GA</Acronym> is a heuristic optimization method which operates through
  89 determined, randomized search. The set of possible solutions for the
  90 optimization problem is considered as a <FirstTerm>population</FirstTerm> of <FirstTerm>individuals</FirstTerm>.
  91 The degree of adaption of an individual to its environment is specified
  92 by its <FirstTerm>fitness</FirstTerm>.
  93 </para>
  94
  95 <Para>
  96    The coordinates of an individual in the search space are represented
  97 by <FirstTerm>chromosomes</FirstTerm>, in essence a set of character strings. A <FirstTerm>gene</FirstTerm> is a
  98 subsection of a chromosome which encodes the value of a single parameter
  99 being optimized. Typical encodings for a gene could be <FirstTerm>binary</FirstTerm> or
 100 <FirstTerm>integer</FirstTerm>.
 101 </para>
 102
 103 <Para>
 104    Through simulation of the evolutionary operations <FirstTerm>recombination</FirstTerm>,
 105 <FirstTerm>mutation</FirstTerm>, and <FirstTerm>selection</FirstTerm> new generations of search points are found
 106 that show a higher average fitness than their ancestors.
 107 </para>
 108
 109 <Para>
 110    According to the "comp.ai.genetic" <Acronym>FAQ</Acronym> it cannot be stressed too
 111 strongly that a <Acronym>GA</Acronym> is not a pure random search for a solution to a
 112 problem. A <Acronym>GA</Acronym> uses stochastic processes, but the result is distinctly
 113 non-random (better than random).
 114
 115 <ProgramListing>
 116 Structured Diagram of a <Acronym>GA</Acronym>:
 117 ---------------------------
 118
 119 P(t)    generation of ancestors at a time t
 120 P''(t)  generation of descendants at a time t
 121
 122 +=========================================+
 123 |>>>>>>>>>>>  Algorithm GA  <<<<<<<<<<<<<<|
 124 +=========================================+
 125 | INITIALIZE t := 0                       |
 126 +=========================================+
 127 | INITIALIZE P(t)                         |
 128 +=========================================+
 129 | evalute FITNESS of P(t)                 |
 130 +=========================================+
 131 | while not STOPPING CRITERION do         |
 132 |   +-------------------------------------+
 133 |   | P'(t)  := RECOMBINATION{P(t)}       |
 134 |   +-------------------------------------+
 135 |   | P''(t) := MUTATION{P'(t)}           |
 136 |   +-------------------------------------+
 137 |   | P(t+1) := SELECTION{P''(t) + P(t)}  |
 138 |   +-------------------------------------+
 139 |   | evalute FITNESS of P''(t)           |
 140 |   +-------------------------------------+
 141 |   | t := t + 1                          |
 142 +===+=====================================+
 143 </ProgramListing>
 144 </para>
 145 </sect1>
 146
 147 <Sect1>
 148 <Title>Genetic Query Optimization (<Acronym>GEQO</Acronym>) in Postgres</Title>
 149
 150 <Para>
 151    The <Acronym>GEQO</Acronym> module is intended for the solution of the query
 152 optimization problem similar to a traveling salesman problem (<Acronym>TSP</Acronym>).
 153 Possible query plans are encoded as integer strings. Each string
 154 represents the <Command>join</Command> order from one relation of the query to the next.
 155 E. g., the query tree
 156 <ProgramListing>
 157        /\
 158       /\ 2
 159      /\ 3
 160     4  1
 161 </ProgramListing>
 162 is encoded by the integer string '4-1-3-2',
 163 which means, first join relation '4' and '1', then '3', and
 164 then '2', where 1, 2, 3, 4 are relids in <ProductName>Postgres</ProductName>.
 165 </para>
 166
 167 <Para>
 168    Parts of the <Acronym>GEQO</Acronym> module are adapted from D. Whitley's Genitor
 169 algorithm.
 170 </para>
 171
 172 <Para>
 173    Specific characteristics of the <Acronym>GEQO</Acronym> implementation in <ProductName>Postgres</ProductName>
 174 are:
 175
 176 <ItemizedList Mark="bullet" Spacing="compact">
 177 <ListItem>
 178 <Para>
 179 Usage of a <FirstTerm>steady state</FirstTerm> <Acronym>GA</Acronym> (replacement of the least fit
 180    individuals in a population, not whole-generational replacement)
 181    allows fast convergence towards improved query plans. This is
 182    essential for query handling with reasonable time;
 183 </Para>
 184 </ListItem>
 185
 186 <ListItem>
 187 <Para>
 188 Usage of <FirstTerm>edge recombination crossover</FirstTerm> which is especially suited
 189    to keep edge losses low for the solution of the <Acronym>TSP</Acronym> by means of a <Acronym>GA</Acronym>;
 190 </Para>
 191 </ListItem>
 192
 193 <ListItem>
 194 <Para>
 195 Mutation as genetic operator is deprecated so that no repair
 196    mechanisms are needed to generate legal <Acronym>TSP</Acronym> tours.
 197 </Para>
 198 </ListItem>
 199 </ItemizedList>
 200 </para>
 201
 202 <Para>
 203    The <Acronym>GEQO</Acronym> module gives the following benefits to the <ProductName>Postgres</ProductName> DBMS
 204 compared to the <ProductName>Postgres</ProductName> query optimizer implementation:
 205
 206 <ItemizedList Mark="bullet" Spacing="compact">
 207 <ListItem>
 208 <Para>
 209 Handling of large <Command>join</Command> queries through non-exhaustive search;
 210 </Para>
 211 </ListItem>
 212
 213 <ListItem>
 214 <Para>
 215 Improved cost size approximation of query plans since no longer
 216    plan merging is needed (the <Acronym>GEQO</Acronym> module evaluates the cost for a
 217    query plan as an individual).
 218 </Para>
 219 </ListItem>
 220 </ItemizedList>
 221 </para>
 222
 223 </Sect1>
 224
 225 <Sect1>
 226 <Title>Future Implementation Tasks for <ProductName>Postgres</ProductName> <Acronym>GEQO</Acronym></Title>
 227
 228 <Sect2>
 229 <Title>Basic Improvements</Title>
 230
 231 <Sect3>
 232 <Title>Improve freeing of memory when query is already processed</Title>
 233
 234 <Para>
 235 With large <Command>join</Command> queries the computing time spent for the genetic query
 236 optimization seems to be a mere <Emphasis>fraction</Emphasis> of the time
 237  <ProductName>Postgres</ProductName>
 238 needs for freeing memory via routine <Function>MemoryContextFree</Function>,
 239 file <FileName>backend/utils/mmgr/mcxt.c</FileName>.
 240 Debugging showed that it get stucked in a loop of routine
 241 <Function>OrderedElemPop</Function>, file <FileName>backend/utils/mmgr/oset.c</FileName>.
 242 The same problems arise with long queries when using the normal
 243 <ProductName>Postgres</ProductName> query optimization algorithm.
 244 </para>
 245 </sect3>
 246
 247 <Sect3>
 248 <Title>Improve genetic algorithm parameter settings</Title>
 249
 250 <Para>
 251 In file <FileName>backend/optimizer/geqo/geqo_params.c</FileName>, routines
 252 <Function>gimme_pool_size</Function> and <Function>gimme_number_generations</Function>,
 253 we have to find a compromise for the parameter settings
 254 to satisfy two competing demands:
 255 <ItemizedList Spacing="compact">
 256 <ListItem>
 257 <Para>
 258 Optimality of the query plan
 259 </Para>
 260 </ListItem>
 261 <ListItem>
 262 <Para>
 263 Computing time
 264 </Para>
 265 </ListItem>
 266 </ItemizedList>
 267 </para>
 268 </sect3>
 269
 270 <Sect3>
 271 <Title>Find better solution for integer overflow</Title>
 272
 273 <Para>
 274 In file <FileName>backend/optimizer/geqo/geqo_eval.c</FileName>, routine
 275 <Function>geqo_joinrel_size</Function>,
 276 the present hack for MAXINT overflow is to set the <ProductName>Postgres</ProductName> integer
 277 value of <StructField>rel->size</StructField> to its logarithm.
 278 Modifications of <StructName>Rel</StructName> in <FileName>backend/nodes/relation.h</FileName> will
 279 surely have severe impacts on the whole <ProductName>Postgres</ProductName> implementation.
 280 </para>
 281 </sect3>
 282
 283 <Sect3>
 284 <Title>Find solution for exhausted memory</Title>
 285
 286 <Para>
 287 Memory exhaustion may occur with more than 10 relations involved in a query.
 288 In file <FileName>backend/optimizer/geqo/geqo_eval.c</FileName>, routine
 289 <Function>gimme_tree</Function> is recursively called.
 290 Maybe I forgot something to be freed correctly, but I dunno what.
 291 Of course the <StructName>rel</StructName> data structure of the <Command>join</Command> keeps growing and
 292 growing the more relations are packed into it.
 293 Suggestions are welcome :-(
 294 </para>
 295 </sect3>
 296 </sect2>
 297
 298
 299 <BIBLIOGRAPHY Id="geqo-biblio">
 300 <TITLE>
 301 References
 302 </TITLE>
 303 <PARA>Reference information for <Acronym>GEQ</Acronym> algorithms.
 304 </PARA>
 305 <BIBLIOENTRY>
 306
 307 <BOOKBIBLIO>
 308 <TITLE>
 309 The Hitch-Hiker's Guide to Evolutionary Computation
 310 </TITLE>
 311 <AUTHORGROUP>
 312 <AUTHOR>
 313 <FIRSTNAME>J&ouml;rg</FIRSTNAME>
 314 <SURNAME>Heitk&ouml;tter</SURNAME>
 315 </AUTHOR>
 316 <AUTHOR>
 317 <FIRSTNAME>David</FIRSTNAME>
 318 <SURNAME>Beasley</SURNAME>
 319 </AUTHOR>
 320 </AUTHORGROUP>
 321 <PUBLISHER>
 322 <PUBLISHERNAME>
 323 InterNet resource
 324 </PUBLISHERNAME>
 325 </PUBLISHER>
 326 <ABSTRACT>
 327 <Para>
 328 FAQ in <ULink url="news://comp.ai.genetic">comp.ai.genetic</ULink>
 329 is available at <ULink url="ftp://ftp.Germany.EU.net/pub/research/softcomp/EC/Welcome.html">Encore</ULink>.
 330 </Para>
 331 </ABSTRACT>
 332 </BOOKBIBLIO>
 333
 334 <BOOKBIBLIO>
 335 <TITLE>
 336 The Design and Implementation of the Postgres Query Optimizer
 337 </TITLE>
 338 <AUTHORGROUP>
 339 <AUTHOR>
 340 <FIRSTNAME>Z.</FIRSTNAME>
 341 <SURNAME>Fong</SURNAME>
 342 </AUTHOR>
 343 </AUTHORGROUP>
 344 <PUBLISHER>
 345 <PUBLISHERNAME>
 346 University of California, Berkeley Computer Science Department
 347 </PUBLISHERNAME>
 348 </PUBLISHER>
 349 <ABSTRACT>
 350 <Para>
 351 File <FileName>planner/Report.ps</FileName> in the 'postgres-papers' distribution.
 352 </Para>
 353 </ABSTRACT>
 354 </BOOKBIBLIO>
 355
 356 <BOOKBIBLIO>
 357 <TITLE>
 358 Fundamentals of Database Systems
 359 </TITLE>
 360 <AUTHORGROUP>
 361 <AUTHOR>
 362 <FIRSTNAME>R.</FIRSTNAME>
 363 <SURNAME>Elmasri</SURNAME>
 364 </AUTHOR>
 365 <AUTHOR>
 366 <FIRSTNAME>S.</FIRSTNAME>
 367 <SURNAME>Navathe</SURNAME>
 368 </AUTHOR>
 369 </AUTHORGROUP>
 370 <PUBLISHER>
 371 <PUBLISHERNAME>
 372 The Benjamin/Cummings Pub., Inc.
 373 </PUBLISHERNAME>
 374 </PUBLISHER>
 375 </BOOKBIBLIO>
 376
 377 </BIBLIOENTRY>
 378 </BIBLIOGRAPHY>
 379
 380 </sect1>
 381 </Chapter>
 382
 383 <!-- Keep this comment at the end of the file
 384 Local variables:
 385 mode:sgml
 386 sgml-omittag:nil
 387 sgml-shorttag:t
 388 sgml-minimize-attributes:nil
 389 sgml-always-quote-attributes:t
 390 sgml-indent-step:1
 391 sgml-indent-data:t
 392 sgml-parent-document:nil
 393 sgml-default-dtd-file:"./reference.ced"
 394 sgml-exposed-tags:nil
 395 sgml-local-catalogs:("/usr/lib/sgml/catalog")
 396 sgml-local-ecat-files:nil
 397 End:
 398 -->