PostgreSQLのGEQO（遺伝子クエリ最適化）の変更

PostgreSQLのGEQO機能に沿った機能を実装する必要があります。GEQOのアプローチはクエリプランを整数文字列としてエンコードすることであり、GEQOはこれらの可能な結合シーケンスをランダムに生成することを理解しています。ソース：http : //www.postgresql.org/docs/9.3/static/geqo-pg-intro.html

私の質問：正しい結合シーケンスを明確に知っている場合にGEQO関数を変更し、異なる結合シーケンスを検索する必要がないようにする方法。たとえば、4つの関係を結合する最適な方法が4-1-3-2であることがわかっていれば、他の順列をチェックする必要はありません。

GEQOがPostgreSQLにどのように実装されているかについての良い資料はありません。PostgreSQLはGEQO機能の全体像のみを提供しますが、あまり説明しません。

または、GEQOを使用せずにstandard_join_search（）自体でこの機能を実現できますか？

postgresql optimization

— user2761431
ソース

クエリヒントを実装したいようです。これはすべて順調ですが、プロジェクトコミュニティはクエリヒントの大ファンとは言えないため、PostgreSQLコアで変更が受け入れられることを期待しないでください。これについて真剣に考えている場合は、クエリプランナーコードをかなり読む必要があり、パーサーからリライタを介してプランナにヒントを渡す方法を理解する必要があります。ここには簡単な答えはありません。最終的には、プランナー/オプティマイザーで特定のパスを強制的に選択します。

— クレイグリンガー

ああ、そうです、彼らはクエリヒントについて懐疑的です。プランナーコードの読み取りを完了しました。GEQOは既存のコアへの変更を最小限に抑える方法になると思われます。

— user2761431 14年

これは、クエリヒントを実装して結合順序を強制するために達成しようとしていることですか？その場合、他の誰かが既にそれを実装しているかどうかを調べてください。また、なぜそれが必要なのか、最初に計画者が間違った選択をしている理由も考慮する必要があります。自己完結型のテストケースを作成し、pgsql-performanceに報告することを検討してください。

— クレイグリンガー

pg_hint_plan：en.sourceforge.jp/projects/pghintplanがありますが、私は使用しませんでした。あるdbaは、9.2で動作していると言った。それについてのロシア語の記事もありますhabrahabr.ru/post/169751

— ckorzhik 14

GEKOをいじる必要なくこれを実行できる1つの方法は、CTEを使用することです。

CTEは最適化の障壁であるため、CTE内で必要な順序で結合をラップできますが、PGは強制的にそうします。

たとえば、最初にt1をt2に結合してから、t4にのみ結合するようにDBを強制する場合、次のように実行できます。

explain 
with j1 as (select *,t1.c4 as t1c4 from t1 join t2 on (t1.c2=t2.id))
    ,j2 as (select * from j1 join t4 on (t1c4=t4.id))
select * from j2;

これにより、次の結果が得られます。

                                  QUERY PLAN                                   
-------------------------------------------------------------------------------
CTE Scan on j2  (cost=51485.00..67785.00 rows=815000 width=64)
CTE j1
 ->  Hash Join  (cost=3473.00..14521.00 rows=815000 width=40)
       Hash Cond: (t2.id = t1.c2)
       ->  Seq Scan on t2  (cost=0.00..26.30 rows=1630 width=20)
       ->  Hash  (cost=1637.00..1637.00 rows=100000 width=20)
             ->  Seq Scan on t1  (cost=0.00..1637.00 rows=100000 width=20)
CTE j2
 ->  Hash Join  (cost=289.00..36964.00 rows=815000 width=64)
       Hash Cond: (j1.t1c4 = t4.id)
       ->  CTE Scan on j1  (cost=0.00..16300.00 rows=815000 width=44)
       ->  Hash  (cost=164.00..164.00 rows=10000 width=20)
             ->  Seq Scan on t4  (cost=0.00..164.00 rows=10000 width=20)
(13 rows)

これは単なる例であり、必要に応じて変更できます。いずれの場合も、PGは異なるCTE間の順序を変更できません。

それが役に立てば幸い：）

— コヘンジョ
ソース