mirror of https://github.com/postgres/postgres
parent
c9ead90ea3
commit
7507e6b5fc
@ -0,0 +1,59 @@ |
|||||||
|
|
||||||
|
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= |
||||||
|
* 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. |
Loading…
Reference in new issue