mirror of
				https://github.com/postgres/postgres.git
				synced 2025-10-31 10:30:33 +03:00 
			
		
		
		
	
		
			
				
	
	
		
			60 lines
		
	
	
		
			2.6 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			60 lines
		
	
	
		
			2.6 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| 
 | |
| =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 | |
| *         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.
 |