Futuras Tareas de Implementación para el OGEC de Postgres

Mejora en la liberación de memoria cuando la consulta ya se ha procesado

Para largas consultas de tipo unión el gasto de tiempo de computación para un optimizar genética de la consulta parece ser una simple fracción del tiempo que necesita Postgres para la liberación de memoria mediante la rutina MemoryContextFree, del archivo backend/utils/mmgr/mcxt.c. Depurando se mostró que se atascaba en un bucle de la rutina OrderedElemPop, archivo backend/utils/mmgr/oset.c. Los mismos problemas aparecieron con consultas largas cuando se usa el algoritmo normal de optimización de Postgres.

Mejora de las configuraciones de los parámetros del algoritmo genético

En el archivo backend/optimizer/geqo/geqo_params.c, rutinas gimme_pool_size y gimme_number_generations, ha de encontrarse un compromiso entre las configuraciones de parámetros para satisfacer dos demandas que compiten:

• Optimización del plan de consulta

• Tiempo de computación

Busqueda de una mejor solución para el desbordamiento de entero

En el archivo backend/optimizer/geqo/geqo_eval.c, rutina geqo_joinrel_size, el valor para el desbordamiento MAXINT esta definido por el valor entero de Postgres, rel->size como su logaritmo. Una modificación de Rel en backend/nodes/relation.h tendrá seguramente impacto en la implementación global de Postgres.

Encotrar solución para la falta de memoria

La falta de memoria puede ocurrir cuando hay más de 10 relaciones involucradas en la consulta. El archivo backend/optimizer/geqo/geqo_eval.c, rutina gimme_tree es llamado recursivamente. Puede ser que olvidase algo para ser liberado correctamente, pero no se que es. Por supuesto la estructura de datos rel de la unión continua creciendo y creciendo; muchas relaciones están empaquetadas dentro de ella. Las sugerencias son bienvenidas :-(