[11/15開催: PostgreSQL Conference Japan 2019 参加受付中] 
他のバージョンの文書 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

13.4. データベースへのデータ投入

データベースにデータを初期投入するために、大量のテーブル挿入操作を行う必要がままあります。 ここでは、そうしたことを効率よく行うためのちょっとしたヒントとテクニックを紹介します。

13.4.1. 自動コミットをオフにする

自動コミットをオフにし、最後に一回だけコミットします。 (普通のSQLでは、これはBEGINを開始時に、COMMITを最後に発行することを意味します。クライアント用ライブラリの中にはこれを背後で実行するものもあります。 その場合は、要望通りにライブラリが行っているかどうかを確認しなければなりません。) 各挿入操作で別個にコミットすることを許すと、PostgreSQLはレコードを追加するたびに多くの仕事をしなければなりません。 1つのトランザクションですべての挿入を行なうことによるもう1つの利点は、1つのレコードの挿入が失敗した場合、その時点までに挿入されたすべてのレコード挿入がロールバックされることです。その結果、一部のみがロードされたデータの対処に困ることはありません。

13.4.2. COPY FROMの使用

1個のコマンドですべてのデータをロードするために一連のINSERTコマンドではなく、COPY FROM STDINを使用してください。 こうするとパーサやプランナその他のオーバーヘッドを減らすことができます。 いずれにしてもこの方法では、コマンドはひとつなので、自動コミットを無効にする必要はありません。

13.4.3. インデックスを削除する

新規に作成したテーブルをロードする時、最速の方法は、テーブルを作成し、COPYを使用した一括ロードを行い、そのテーブルに必要なインデックスを作成することです。 既存のデータに対するインデックスを作成する方が、各行がロードされる度に段階的に更新するよりも高速です。

既存のテーブルに追加しているのであれば、インデックスを削除し、テーブルをロードし、インデックスを再作成することができます。 もちろん、他のユーザから見ると、インデックスが存在しない間データベースの性能は悪化します。 また、一意性インデックスを削除する前には熟考しなければなりません。 一意性制約によるエラー検査がその期間行われないからです。

13.4.4. sort_memを増やす

大規模なデータをリストアする時sort_mem設定変数を一時的に増やすことで性能を向上させることができます。 これは、B-treeインデックスがスクラッチから作成する時に既存のテーブルの内容はソートされている必要があるからです。 より多くのバッファページを使用するマージソートを許可することは、要求されるマージ経路が非常に少ないことを意味します。

13.4.5. 最後にANALYZEを実行

初めてテーブルにデータを投入した直後を含め、大量のデータを追加、更新した時はANALYZEVACUUM ANALYZEを実行することを勧めます。 これにより確実にプランナがテーブルに関する最新の統計情報を持つことができます。 統計情報が存在しない、または古い場合、プランナは、そのテーブルに対する問い合わせの性能を損なわせる、お粗末な問い合わせ計画を選択する可能性があります。