Postgres GEQO におけ る今後の実装作業

基本的な改善

問い合わせ処理完了時のメモリ開放についての改善

大規模 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 全般に大きく影響を与えることにな ります。

メモリ枯渇についての解決策の探求

問い合わせ内に 10 個以上のリレーションがあると、メモリを使い果たして しますことがあります。 backend/optimizer/geqo/geqo_eval.c ファイルでは gimme_tree 処理が再帰的に呼び出されます。おそら く何かをちゃんと開放していないのだと考えているですが、まだ判明できて いません。もちろん joinrel データ構造体はリレーションがあればあるほ ど肥大していきます。何か解決策がないでしょうか :-(

参考資料

GEQアルゴリズム関連情報

The Hitch-Hiker's Guide to Evolutionary Computation, Jrg Heitktter and David Beasley, InterNet resource, The Design and Implementation of the Postgres Query Optimizer, Z. Fong, University of California, Berkeley Computer Science Department, Fundamentals of Database Systems, R. Elmasri and S. Navathe, The Benjamin/Cummings Pub., Inc..

comp.ai.geneticの FAQ は Encore から入手できます。

'postgres-papers' 配布物内の planner/Report.ps ファイル。