[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

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

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

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

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

10.4.2. COPY FROMを使う

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

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

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

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

10.4.4. ANALYZE 結びを実行

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