多くのINSERTとbyteaの更新のためにPostgreSQLを最適化します

私たちが持っているもの（ソフトウェア）：

• 基本構成のPostrgeSQL 9.3（変更なしpostgresql.conf）
• Windows 7 64ビット

ハードウェア：

• インテルCore i7-3770 3.9 Ghz
• 32 Gb RAM
• WDC WD10EZRX-00L4HBAtaドライブ（1000Gb、SATA III）

したがって、DB aproxにロードする必要があります。bytea列を含む100.000.000行、およびより単純な500.000.000行（LOBなし）。1つ目のテーブルには2つのインデックス（長さ13、19）があり、2つ目のテーブルには2 つのインデックス（長さ18、10）があります。各テーブルのID生成のシーケンスもあります。varcharvarchar

現在、これらの操作は、JDBCバッチサイズ50と並行して8つの接続で実行されています。次の図は、システム負荷を示しています。これはpostgresqlプロセスの負荷がゼロです。24時間のロード後、10.000.000行しかロードしていません。これは非常に遅い結果です。

以下のPostrgreSQL目的で、構成の調整について支援を求めています。

1）この量のデータを超高速でロードする場合、これは1回のみの操作であるため、一時的な構成になる可能性があります。

2）結合やソートを行わずに、インデックスによってこれら2つのテーブルに適度な数のSELECTを実行する本番モードの場合。

以下のためにinsertパフォーマンスを参照してくださいPostgreSQLの挿入のパフォーマンス高速化とPostgreSQLの一括挿入を。

のJDBCバッチ処理で時間を無駄にしていますinsert。PgJDBCはinsertバッチでは何の有用なこともせず、各ステートメントを実行するだけです。<-これは、新しいPgJDBCバージョンではもはや当てはまりません。これにより、準備されたステートメントをバッチ処理して、ラウンドトリップ時間を大幅に削減できます。しかし、それでもなお優れています：

COPY代わりに使用してください。PgJDBCバッチコピーおよびを参照してくださいCopyManager。同時ローダーの数については、操作がディスクI / Oバウンドである場合は、ディスクごとに2つを目指します。おそらく8が最も望ましいでしょう。

「プロダクションモード」では、データのサンプルをロードし、実行する予定のクエリを設定し、explain analyzeパフォーマンスの調査に使用することをお勧めします。テストのみを目的として、enable_paramsを使用してさまざまなプランの選択を調査します。問い合わせプランナのコストパラメータ（設定しrandom_page_cost、seq_page_cost、effective_cache_sizeお使いのシステムに適切に、など）、および確認してshared_buffers適切に設定されています。auto_explainモジュール、log_min_duration_statement設定、pg_stat_statements拡張機能などを使用して、シミュレートされた本番ワークロードを追加しながら、監視を続けます。

詳細については、PostgreSQLのユーザーマニュアルを参照してください。explain analyzeクエリ実行の詳細などでより具体的な問題が発生した場合は、ここに戻ることをお勧めします。