2

私は、7億行以上の単一のテーブル(パーティション分割なし)で作業しています。このデータを別のデータベースにロードしたかったので、次の pg_dump コマンドを使用しました。

pg_dump -Fc --column-inserts --data-only --table='tname' -U 
postgres -d dbname > /root/tname_experiment_inserts_custom_format.dump

宛先システムで、次のコマンドを使用しました。

pg_restore -d dest_dbname -U postgres -j 7 /root/tname_experiment_inserts_custom_format.dump

宛先データベースには、復元しようとしていたテーブルが既にあったため、TRUNCATE を使用してから、すべてのインデックスを削除しました。宛先システムには 32GB の物理メモリがあり、postgres 構成ファイルで次の設定を行いました。

log_min_duration_statement = -1
autovacuum = off
maintenance_work_memory = 7gb 
wal_level = minimal
fsync = off
full_page_writes= off
synchronous_commit= off
max_wal_size= 20GB
wal_buffers= 16MB

pg_restore の時間を計ると、1 時間で約 1,600 万行しか挿入されません。つまり、データの復元には 40 時間以上 (!) かかります。その後、削除したインデックスと外部制約を作成する必要があり、これにはさらに数時間かかる場合があります。このプロセス全体をより速くするために、何か違うことをすることができると感じています。このプロセスを効率化するのに役立つヒントがあれば教えてください。また、COPY については既に確認しましたが、主キーの順序が維持されないため、このオプションは適切ではありません。データの順序を保持する COPY の特殊な設定を知らない場合は、知っておくとよいでしょう!

全体の目的は、列のいくつかのデータ型を変更することでした。これは、alter table alter column query を使用して行うと、同様の時間がかかっていました。

4

2 に答える 2