PostgresGEQOに関する 将来の実装作業．

基本的な改善

問い合わせがすでに処理されていた場合のメモリ開放方式を改善．

大規模なjoin問い合わせの際に，遺伝的問い合わせ 最適化により消費される計算時間は，ファイルbackend/utils/mmgr/mcxt.c にあるMemoryContextFreeルーチン経由のメモリ開放において Postgresが必要とする時間のごく一部に過ぎないようです． デバッグしたところによると，ファイル backend/utils/mmgr/oset.c のルーチン OrderedElemPop のループ内で時間がかかっています． 通常のPostgresの問い合わせ最適化 アルゴリズムを使っている時にも，長い問い合わせで同じ問題が 起こります．

遺伝的アルゴリズムのパラメータ設定を改善

ファイル backend/optimizer/geqo/geqo_params.c の中のルーチン gimme_pool_size と gimme_number_generations で，2 つの相反する要求 を満足させるためのパラメータ設定の妥協点を見つけなくてはなりません．

• 問い合わせプランの最適条件

• 計算時間

整数オーバーフローに関するよりよい解決策を見つける

ファイル backend/optimizer/geqo/geqo_eval.c の ルーチン geqo_joinrel_size において， rel->size からその対数への Postgres 整数値をセットするための MAXINT オーバーフローをハックしなければなりません． backend/nodes/relation.h の Rel を変更してしまうと，おそらく Postgres 実装系全体に深刻な影響を及ぼすでしょう．

メモリ枯渇に関する解決策を見つける

1 つの問い合わせの中に 10 以上のリレーションを含んでいる場合， メモリを使い果たしてしまうことがあります． ファイル backend/optimizer/geqo/geqo_eval.c において，ルーチン gimme_tree が再帰的に 呼ばれています． おそらく私が何かを正しく開放していないのだと思うのですが， それが何だか分からずにいます． もちろん join の rel データ構造体が，その中にリレーションを包み込んで行くことにより どんどん肥大しています． 何かいい案はないでしょうか？

将来の改善点

Postgres における深い階層の問い合わせ ツリー処理を可能にする．これは問い合わせプランの品質を向上させます．