2

次のように記述されたSQLサーバーインデックスクエリで SELECT * FROM TabEmp WITH (INDEX(idx_TabEmp))

同様に、postgresql でクエリを記述する方法と、postgresql でインデックスを使用する方法について説明します。

4

1 に答える 1

3

PostgreSQL には非常に高度なプランナーが付属しており、最も効率的な方法でクエリの詳細を配信するために、可能な限りの手段を使用することをお勧めします。

インデックスに関しては、適切な列、おそらくFROM(明示的な表記法)WHEREまたはORDER BY句で使用される列に作成するだけで済みます。ドキュメントが言うように：

インデックスが作成されると、それ以上の介入は必要ありません。システムは、テーブルが変更されるとインデックスを更新し、テーブルの順次スキャンよりも効率的であると判断した場合に、クエリでインデックスを使用します。

もちろん、クエリを処理するためにデータベースが実際に何をしているのかを理解するためにANALYZE、テーブルを調べて出力を調べる必要があります。EXPLAIN

編集

私の日常の主な仕事は、ORACLE 上で動作する一連の Billing プロダクション システムの管理であるため、ヒントが何であるかを知っています。管理者として、私は自分のスキーマとデータをよく知っており、ほとんどの場合、クエリを実行するための最適な計画を知っています。

現在、ORACLE は多くの異なる機能を提供しているため、オプティマイザは可能なパスの量に「追いつく」ことができません。したがって、彼らは別の方法でヒントを追加しました。そして、私はそれらを使用します。なぜなら、関連する関係の統計をどのように処理しても、最適なパフォーマンスが得られるとわかっている特定の計画を強制する方法が他にないからです。

PostgreSQL は別の道を歩みました。ヒントを提供する代わりに、彼らはプランナーを今日のように良くするために多くの時間を費やしていました. 私は感銘を受けました。これは、PostgreSQL が他のすべての RDBMS をリングから追い出すところです。私見では。

はい、常に PostgreSQL で最適な計画が得られるわけではありません。しかし、目標を達成する方法はあります。他の人がすでに指摘しているように：

  1. データを把握し、最適な計画がどのようなものかを把握する必要があります。
  2. http://explain.depesz.com/EXPLAIN (analyze, buffers)と一緒に使用するなど、適切なツールを使用してください。
  3. 適切な統計があることを確認してください。
  4. enable_*設定をいじって、実際に適切な計画を立てます。
  5. それでもうまくいかない場合は、データを調べて、選択したプランが最適ではない理由を理解してください。PostgreSQL がクエリに含まれる特定の属性の統計情報を収集する方法と一致しないデータ分散スキューが見つかると思います。
  6. データの偏りがあることがわかった列を調整SET STATISTICSします。
  7. それでもうまくいかない場合は、範囲またはリストのパーティション分割、部分インデックス、CTE など、他の手法を使用できます。

PostgreSQL での私の経験では、ヒントを使用する必要はまったくありませんでした。ヒントを追加することは「迅速かつ簡単」であるという事実にもかかわらず、データ分散またはデータベースの使用パターンが変化した場合 (非常に一般的なシナリオ) にヒントが悪い仕事をする可能性があるため、パフォーマンスの悪いクエリを一般的な手段で解決することを常に好みます。

私がヒントを目にする唯一の場所は、あなたが使用/サポートしているクローズドソースソフトウェアの生産上の問題を修正することです. ただし、これは、新しいリリースを展開する前に深く徹底的な QA およびパフォーマンス テストを行う場合にも当てはまります。

それでもヒントが必要な場合は、Oleg Bartunov と Teodor Sigaevによるplantunerを参照してください。この拡張機能は標準の PostgreSQL ディストリビューションには含まれていませんが、Oleg と Teodor がコア PostgreSQL 開発チームに属していることを考えると (彼らはプロジェクト用に GIN、GIST、および FTS を作成しました)、コードは非常に安定していると思います。

于 2013-02-18T12:33:01.693 に答える