1 files changed, 0 insertions, 59 deletions
diff --git a/doc/TODO.GEQO b/doc/TODO.GEQO
deleted file mode 100644
index 3e5b9f4f76f..00000000000
--- a/doc/TODO.GEQO
+++ /dev/null
@@ -1,59 +0,0 @@
-
-=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
-*         Things left to done for the PostgreSQL                    *
-=           Genetic Query Optimization (GEQO)                       =
-*              module implementation                                *
-=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
-* Martin Utesch		      * Institute of Automatic Control      *
-=                             = University of Mining and Technology =
-* utesch@aut.tu-freiberg.de   * Freiberg, Germany                   *
-=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
-
-
-1.) Basic Improvements
-===============================================================
-
-a) improve freeing of memory when query is already processed:
--------------------------------------------------------------
-with large JOIN queries the computing time spent for the genetic query
-optimization seems to be a mere *fraction* of the time Postgres
-needs for freeing memory via routine 'MemoryContextFree',
-file 'backend/utils/mmgr/mcxt.c';
-debugging showed that it get stucked in a loop of routine
-'OrderedElemPop', file 'backend/utils/mmgr/oset.c';
-the same problems arise with long queries when using the normal
-Postgres query optimization algorithm;
-
-b) improve genetic algorithm parameter settings:
-------------------------------------------------
-file 'backend/optimizer/geqo/geqo_params.c', routines
-'gimme_pool_size' and 'gimme_number_generations';
-we have to find a compromise for the parameter settings
-to satisfy two competing demands:
-1.  optimality of the query plan
-2.  computing time
-
-c) find better solution for integer overflow:
----------------------------------------------
-file 'backend/optimizer/geqo/geqo_eval.c', routine
-'geqo_joinrel_size';
-the present hack for MAXINT overflow is to set the Postgres integer
-value of 'rel->size' to its logarithm;
-modifications of 'struct Rel' in 'backend/nodes/relation.h' will
-surely have severe impacts on the whole PostgreSQL implementation.
-
-d) find solution for exhausted memory:
---------------------------------------
-that may occur with more than 10 relations involved in a query,
-file 'backend/optimizer/geqo/geqo_eval.c', routine
-'gimme_tree' which is recursively called;
-maybe I forgot something to be freed correctly, but I dunno what;
-of course the 'rel' data structure of the JOIN keeps growing and
-growing the more relations are packed into it;
-suggestions are welcome :-(
-
-
-2.) Further Improvements
-===============================================================
-Enable bushy query tree processing within PostgreSQL;
-that may improve the quality of query plans.