PostgreSQLチューニングのベストプラクティス

Question

Postgres for OLTPアプリケーションのパフォーマンスのチューニングと最適化の方法に関するオンラインガイドと印刷ガイドがたくさんありますが、データウェアハウスアプリケーション固有のソートは見つかりませんでした。ワークロードの種類には多くの違いがあるため、データベースの管理方法やチューニング方法にはいくつかの違いがあります。

私自身のいくつか：私は通常、1日1回のみのインサートを心配して、インデックスの再構築でバッチ挿入を行うことができますので、私は、私はより多くの自由索引を使用するDDL側から発見した

• を。

• 私は一般的に、通常より速く

• に参加し、私は通常、日付操作（会計期間を事前に作成している非常に包括的な日付テーブルを定義し、維持するための1つの自然キーよりも多くを持っているデータに整数代理キーを使用します。カレンダーの日付、会計年月、曜日の開始日などに反して）、selectステートメントとwhereステートメントで関数を使用するのではなく、それを自由に使用します。これは、通常、CPUバインド集約クエリ中に役立ちます。

私はメモリ管理およびその他のデータベース設定に関するいくつかの情報を見つけるだろうと期待していたが、私はPostgresのベースのデータ・ウェアハウスに固有の任意の有用なベストプラクティスを聞いて幸せになります。

Answer 1

メモリ管理の観点からは、最も大きな違いの1つは、動作中のOLTPをメモリに保持することができ、OLAP環境ではそうでない場合が多いことです。さらに、非常に頻繁に結合セットが大きくなります。これは、より高いwork_mem設定が非常に役に立ち、テーブルが非正規化されていることを意味します。これは、work_memを他の場合よりも少し高く押すことができることを意味します。私はshared_buffersに関する私のアドバイスが変わるだろうと確信していません（私は低いレベルから始め、それぞれのステップでパフォーマンスをテストすることを好む）が、どんなサイズのセットでも報告をしているならwork_memを増やす必要があります。

Answer 2

（確かにかなり小規模で、それがデータウェアハウスに来るとき）私の経験：それはそのデータの量を減らすようにあなたのような

• 言うまでもなく、事前集計データは、簡単に、最も重要なことです多くの桁で読み取る必要があります。
• トランザクション、サブトランザクション、セーブポイントの書き込みを避けてください。これには、PL/pgSQLにおける例外処理も含まれます。これらは、利用可能な「トランザクションID」スペースをすばやく焼き付け、expensive "wraparound" vacuums that need to rewrite whole tablesを引き起こします。
• 各パーティションをカーネルのキャッシュに個別に収めることができるようなパーティションテーブルがあることが分かっていれば、メンテナンスと移行には良いことが分かりました。つまり、インデックスごとに1回スキャンするのではなく、ディスクからわずか1セグスキャンでパーティションのすべてのインデックスを再作成できます。
• Chrisがすでに述べたように、work_memとmaintenance_work_memで十分に気をつけてください。あなたのワークロードがRAMに収まらない場合は、より一時的なデータをメモリに保持することで、よりスマートなクエリプラン（最も重要なのはHashAggregate）によりI/OとCPU時間が節約されます。
• 大規模なソートが必要な場合は、テンポラリファイルを格納するための専用SSDを購入することができます。