2

残念ながら、いくつかの重いbyteaタイプのフィールドを含む、顧客データ (〜 500K の顧客) を含むテーブルを備えた postgresql 9.2 インストールがあります。

CUSTOMERS1 |    id    |   first name  |  last name  |   ...
-----------------------------------------------------   ...
               c1005         ...            ...         ...

残念ながら、まったく同じ外部キーを使用していない外部ソースとデータをマージするタスクがあります。

CUSTOMERS2 |    id    |   first name  |  last name  |   ...
-----------------------------------------------------   ...
              101005         ...            ...         ...

そのため、は同じ idにid をcustomers1持っています。つまり、はドロップされ、id に追加されます。c1005customers2101005c100000

にあるのと同じIDを含む列customers2_idを追加しようとしています。次のSQLコマンドを思いつきました：customers1customers2

ALTER TABLE customers1 ADD COLUMN customers2_id numeric(15,0);
UPDATE customers1 
SET customers2_id = to_number(trim(leading 'c' from id), '9999') + 100000;

残念ながら、コマンドを実行すると、永遠に時間がかかります (15 時間以上実行しても、まだ完了していません)。さらに、postgres プロセスはアイドル状態のようです (アクティビティ モニターによると)。

いくつかのメモ:

  • インデックスを削除しました
  • UPDATEeg を使用してコマンドを実行するWHERE id = 'c1005'と、WHERE 句に最大 10 個の要素が含まれるまで高速に実行され、20 個の要素では速度が大幅に低下します
  • この実験は、この操作を高速に実行できることを示しましINSERT INTOた。新しいテーブルを作成し、select ステートメントを挿入した値として指定しましたSELECT id, to_number(trim(leading 'c' from id), '9999') + 100000 FROM customers2。10秒未満で実行されます
  • bytea フィールドが主な問題であるという印象があります。

どうすれば物事をスピードアップし、この問題を解決できるでしょうか? それほど遅いという本当の問題は何でしょうか?

4

1 に答える 1

2

テーブルが壊れていたようです。スキーマを再作成してテーブルをコピーしましたINSERT INTO(便宜上、新しい id フィールドを新しいスキーマに追加し、挿入時に新しい id を計算させました)。今、すべてがスムーズに機能します。

于 2013-06-18T12:53:14.923 に答える