問題タブ [postgresql-performance]

作成する単体テストごとに、メモリ内でのみ実行される小さなPostgreSQLデータベースを実行したいと思います。例えば：

理想的には、単体テストで使用するバージョン管理に1つのpostgres実行可能ファイルをチェックインします。

のようなものHSQLですが、postgres用です。どうやってやるの？

そのようなPostgresバージョンを入手できましたか？ディスクを使用しないように指示するにはどうすればよいですか？

基本的なPostgreSQLサーバー構成パラメーターを調整してクエリを最適化する必要があります。work_memドキュメントで私はパラメータに出くわしました。次に、このパラメーターを変更すると、クエリのパフォーマンスにどのように影響するかを確認しました（並べ替えを使用）。さまざまな設定でクエリの実行時間を測定work_memしましたが、非常にがっかりしました。

クエリを実行するテーブルには10,000,000行が含まれており、並べ替えるデータは430MBです。（Sort Method: external merge Disk: 430112kB）。

を使用work_mem = 1MBすると、EXPLAIN出力は次のようになります。

とwork_mem = 5MB：

とwork_mem = 64MB：

パフォーマンスが悪化する理由を誰かが説明できますか？または、サーバーパラメータを変更してクエリの実行を高速化する他の方法を提案しますか？

私のクエリ（最適ではないことはわかっていますが、この種のクエリのベンチマークを行う必要があります）：

完全な実行計画：

PostgreSQL 8.4.9 を使用して、クエリに対する PostgreSQL のパフォーマンスに奇妙な問題があります。LEFT OUTER JOINこのクエリは、関連 ID が存在する関連 ID 列を追加するためにを使用して、3D ボリューム内のポイントのセットを選択しています。範囲を少し変更すると、xPostgreSQL が別のクエリ プランを選択する可能性があり、実行時間が 0.01 秒から 50 秒になります。これが問題のクエリです。

そのクエリには 1 分近くかかります。そのクエリEXPLAINの前に追加すると、次のクエリ プランが使用されているようです。

ただし、範囲内条件を に置き換える8000とx、10644クエリは一瞬で実行され、次のクエリ プランが使用されます。

私はこれらのクエリ プランの解析の専門家にはほど遠いですが、明確な違いは、あるx範囲ではHash Left Join(LEFT OUTER JOIN非常に高速な) を使用し、他の範囲では (非常に高速なNested Loop Left Joinようです) を使用することです。スロー）。どちらの場合も、クエリは約 90 行を返します。SET ENABLE_NESTLOOP TO FALSE遅いバージョンのクエリの前に行うと、非常に高速になりますが、一般的にその設定を使用することは悪い考えであることを理解しています.

たとえば、クエリ プランナーが明らかにより効率的な戦略を選択する可能性を高めるために、特定のインデックスを作成できますか? なぜ PostgreSQL のクエリ プランナーがこれらのクエリの 1 つに対してこのような貧弱な戦略を選択しなければならないのか、誰かが提案できますか? 以下に、役立つと思われるスキーマの詳細を示します。

treenode テーブルには 900,000 行あり、次のように定義されています。

複合型は次のdouble3dように定義されます。

結合に関係する他の 2 つのテーブルは次のtreenode_class_instanceとおりです。

...そしてclass_instance：

PG データベースから約 200 万行を削除する必要があります。削除する必要がある ID のリストがあります。ただし、これを行うには何日もかかります。

それらをテーブルに入れて、100のバッチで実行しようとしました.4日後、これはまだ297268行が削除されたまま実行されています. （IDテーブルから100個のIDを選択し、そのリストのどこを削除し、選択した100個をIDテーブルから削除する必要がありました）。

私は試した：

それも永遠にかかります。完了するまで進行状況を確認できないため、どれくらいの時間を測定するのが難しいですが、クエリは 2 日後も実行されていました。

削除する特定のIDがわかっているときにテーブルから削除する最も効果的な方法を探しているだけで、何百万ものIDがあります。

この質問STRICTに答えているときに、単純な SQL 関数を宣言すると、パフォーマンスが低下することに遭遇しました。

デモンストレーションのために、配列の 2 つの要素を昇順で並べ替える関数の 2 つのバリアントを作成しました。

テスト設定

整数の 10000 のランダムなペアを持つテーブル (

STRICT修飾子なしの関数:

修飾子付きの関数STRICT(それ以外は同一):

結果

私はそれぞれ約20回実行し、最高の結果を得ましたEXPLAIN ANALYZE.

これらは、Debian Squeeze での Postgres 9.0.5 の結果です。8.4でも同様の結果。

すべての NULL 値を使用したテストでは、両方の関数が同じように実行されます: ~37 ミリ秒。

私はいくつかの調査を行い、興味深い落とし穴を見つけました。SQL 関数STRICT を宣言すると、ほとんどの場合、関数のインライン展開が無効になります。詳細については、PostgreSQL オンライン ジャーナル、pgsql-performance メーリング リスト、またはPostgres Wikiを参照してください。

しかし、これがどのように説明できるかはよくわかりません。関数をインライン化しないと、この単純なシナリオでパフォーマンスが低下しますか? インデックスなし、ディスク読み取りなし、ソートなし。関数をインライン化することによって合理化された、繰り返しの関数呼び出しによるオーバーヘッドでしょうか?

再テスト

同じテスト、同じハードウェア、Postgres 9.1 . さらに大きな違い:

同じテスト、新しいハードウェア、Postgres 9.6。ギャップはさらに大きくなりますが、次のようになります。

PostgreSQL 9 バックエンドを使用するアプリケーションでスケーリングの問題が発生しています。サイズが約 4,000 万レコードで、成長している 1 つのテーブルがあり、それに対する条件付きクエリが劇的に遅くなりました。

何が問題なのかを把握するために、データベースの開発スナップショットを作成し、クエリと実行時間をログに記録しました。

さて、紛らわしい部分と質問の要点について....

ログ内のクエリの実行時間は、説明計画を取得するために DbVisualizer で「まったく同じ」クエリを実行した場合とは大きく異なります (桁違い +)。

「正確」と言いますが、実際の違いは、アプリケーションが実行時に値をバインドする準備済みステートメントを使用しているのに対し、DbVisualizer で実行するクエリにはそれらの値が既に配置されていることです。値自体は、ログから取得したものとまったく同じです。

準備済みステートメントを使用すると、それほど大きな違いが生じるでしょうか?

クエリ:

を設定SET enable_seqscan = offすると、次のような高速処理が実行されます。

しかし、恐ろしい enable_seqscan がなければ、より遅いことを選択します。

関連するインデックスは次のとおりです。

だから私の質問は、Postgres が参加する 2 つの方法の相対的なコストを誤って見積もっているということです。コストの見積もりで、ハッシュ結合が高速になると考えていることがわかります。そして、インデックス結合のコストの見積もりは、500 倍ずれています。

Postgresにもっと手がかりを与えるにはどうすればよいですか? 上記のすべてを実行するVACUUM ANALYZE直前に実行しました。

興味深いことに、ゲーム数が少ないプレイヤーに対してこのクエリを実行すると、Postgres はインデックス スキャン + ネスト ループを実行することを選択します。したがって、多数のゲームについての何かが、相対的な推定コストが実際の推定コストと一致しないこの望ましくない動作をくすぐります。

最後に、Postgres を使用する必要がありますか? 私はデータベース チューニングの専門家になりたいわけではないので、専任の DBA とは対照的に、良心的な開発者レベルの注意を払って適切に機能するデータベースを探しています。私が Postgres を使い続けると、このような問題が絶え間なく発生し、Postgres の専門家にならざるを得なくなるのではないかと心配しています。

Postgres の専門家 (RhodiumToad) が私の完全なデータベース設定 ( http://pastebin.com/77QuiQSp ) をレビューし、 set cpu_tuple_cost = 0.1. それは劇的なスピードアップをもたらしました: http://pastebin.com/nTHvSHVd

または、MySQL に切り替えることで、問題もかなりうまく解決しました。私の OS X ボックスには MySQL と Postgres のデフォルト インストールがあり、MySQL は 2 倍高速であり、クエリを繰り返し実行することによって「ウォームアップ」されたクエリを比較しています。「コールド」クエリ、つまり特定のクエリが初めて実行されるとき、MySQL は 5 ～ 150 倍高速です。コールド クエリのパフォーマンスは、特定のアプリケーションにとって非常に重要です。

私に関する限り、大きな問題はまだ未解決です。Postgres を適切に実行するには、MySQL よりも多くの調整と構成が必要ですか? たとえば、ここでコメンターが提供した提案がどれも機能しなかったと考えてください。

テーブルに類似した文字列のランキングを作成する必要があります。

私は次の表を持っています

現在、関数を提供するpg_trgmモジュールを使用していますsimilarityが、効率に問題があります。Postgresのマニュアルが示唆するようなインデックスを作成しました：

そして私は次のクエリを実行しています：

クエリは機能しますが、名前が数百ある場合は非常に遅くなります。and sim > .8さらに、SQLを少し忘れたかもしれませんが、「列simが存在しません」というエラーが発生せずに条件を使用できない理由がわかりません。

クエリを高速化するためのヒントが欲しいのですが。

CREATE TABLEPostgresでは、ステートメントの列の順序はパフォーマンスに影響しますか？次の2つのケースを考えてみましょう。

対。

列のバイトアラインメントが優れているためfoo2よりもパフォーマンスが向上しますか？fooPostgresを実行するCREATE TABLEと、指定された列の順序に従いますか、それともバイトの配置やパフォーマンスに最適な順序で列を再編成しますか？

PostgreSQL 9.1.1 と Rails 3.2.8 を使用しています。NewRelic の開発モードを使用して、いくつかの SQL クエリで、サーバーの起動または再起動に続く最初のリクエストのほうが、後続のリクエストよりもはるかに長い時間がかかることに気付きました。

その理由はありますか、それは準備されたステートメントによるものですか？