3

次のクエリを 3 時間以上実行しています。

UPDATE eop_201007
set coord_x = gi.x_etrs89, coord_y = gi.x_etrs89,gr_type = 4
from eop_201007 as eop, geoindex201001 as gi
where eop.cp7=gi.cp7 AND eop.gr_type=0;

eop テーブルには 30 万以上のレコードがあり、gi テーブルには 10 万以上のレコードがあります。

cp7 フィールドは両方のテーブルでインデックス化されており、完了するまでに時間がかかりすぎています。

私はそれを間違っていますか？どうすればこれを改善できますか?

4

2 に答える 2

1

FROMに「eop_201007aseop」は必要ありません。以下が機能します。

UPDATE eop_201007
set coord_x = gi.x_etrs89, coord_y = gi.x_etrs89,gr_type = 4
from geoindex201001 as gi
where eop_201007.cp7=gi.cp7 AND eop_201007.gr_type=0;

余分なeopは、FROMリストに「自動的に」含まれている元のeopテーブルに対して制約されていないため、相互結合（基本的には2つのテーブルの外積である巨大なもの）を引き起こしていると思います。

それでも問題が解決しない場合は、他にいくつか考えてみましょう。

まだ行っていない場合は、最初に真空分析を実行することをお勧めします。postgresql.confにすべてのメモリ設定が調整されていることを確認してください。ワーキングメモリ、共有バッファなどは大きな違いを生む可能性があります。

これが1回限りの作業であり、夜間の作業ではない場合は、fsyncをオフにする必要があります。また、（fsyncをオフにする場合）構成されているチェックポイントセグメントが多すぎないことを確認してください（24程度で構成されます）。そうしないと、ディスクキャッシュが汚染されます。

@Frank Heikensが言ったように、あなたは説明を見る必要があります。EXPLAIN ANALYZEもチェックしてください（クエリが終了した場合）。

于 2010-08-18T10:01:26.357 に答える
1

このトピックを確認し、EXPLAIN を使用して何が起こっているかを確認してください。更新中にメモリ使用量と書き込み速度を確認するだけで、 WALのより良い構成も役立つ場合があります。

編集：そして、他のトランザクションがテーブルをロックしていないことを確認してください。永遠に待たなければなりません...

SELECT 
    relname, 
    * 
FROM 
    pg_locks
        JOIN pg_class ON pg_locks.relation  = pg_class.oid
于 2010-08-17T10:52:41.143 に答える