对于大型 join 查询，遗传查询优化所花费的计算时间似乎只是 Postgres 通过例程 MemoryContextFree（文件 backend/utils/mmgr/mcxt.c）释放内存所用时间的一个小分数。调试显示它卡在了例程 OrderedElemPop（文件 backend/utils/mmgr/oset.c）的一个循环中。使用普通 Postgres 查询优化算法处理长查询时也会出现同样的问题。

在文件 backend/optimizer/geqo/geqo_params.c 的例程 gimme_pool_size 和 gimme_number_generations 中，我们必须为参数设置找到一种折中，以满足两个相互竞争的需求：

在文件 backend/optimizer/geqo/geqo_eval.c 的例程 geqo_joinrel_size 中，目前对 MAXINT 溢出的临时做法是把 Postgres 整数值 rel->size 设为其对数。对 backend/nodes/relation.h 中 Rel 的修改肯定会对整个 Postgres 实现产生严重影响。

当查询涉及的关系超过 10 个时可能发生内存耗尽。在文件 backend/optimizer/geqo/geqo_eval.c 中，例程 gimme_tree 会被递归调用。也许我忘了正确释放某些东西，但我不知道是什么。当然，join 的 rel 数据结构会随着装进去的关系越来越多而不断增长。欢迎建议 :-(