2016-04-27 12 views
0

私は30万のレコードを持つ非常に大きなテーブルからレコードを削除するクエリを持っています。私はこの小さなクエリを5回実行したときに10kレコードのような小さな塊でレコードを削除しています。postgresqlの削除操作のトランザクションブロック。ログ?

しかしそれ以降は出てこない。今でも10レコードまで削除することはできません。私はそれが巨大なトランザクションログを生成している可能性があります。それがそうであれば、何らかの体制でトランザクションログをクリアする方法を教えてください。私が削除クエリで変更する必要があるものがあれば?あなたは(時間の回復で停電またはポイントの後に)復元しているとき、または複製を行う際にログサイズを見つけるために、任意のクエリでは?私はpostgresの9.1

WITH ids_to_delete as(
    SELECT rh.dp_value_id 
    FROM raw_dp_links rh LEFT OUTER JOIN dp_values dp 
    ON rh.dp_value_id=dp.dp_value_id 
    where dp.dp_value_id is null 
    limit 10000 
    ) 
    delete from raw_dp_links where dp_value_id in (select dp_value_id from ids_to_delete) 
+2

ほとんどの場合、クエリはロックを待機しています。こちらをご覧ください:https://wiki.postgresql.org/wiki/Lock_Monitoring WALセグメントのサイズ(Postgresに「トランザクションログ」というものはありません)が大きすぎる場合は、エラーメッセージ –

+0

はいなぜなら、単純な削除操作でロックが取得されているのはなぜですか? – SUDARSHAN

+1

あなたのdeleteステートメントはロックされません。おそらく、それらの行を変更する他のトランザクションがあります。または、参照先テーブルが変更されている外部キー。 wikiページを読んで文を実行して、これらのロックの原因を調査してください。それ以上の情報なしで言うことは不可能です。 –

答えて

0

ファーストを使用しています、PostgreSQLのトランザクションログは、主要因です。 PostgreSQLがディスク上のストレージを扱う方法のために、トランザクションからの大きなログセグメントはあなたに問題を与えません。 PostgreSQLでは、非同期ガベージコレクション(自動バキューム)を使用するヒープテーブル(インデックスの周りには順序付けされていません)が使用されているため、ログセグメントが問題となる唯一のポイントはトランザクションコミットです。

同じテーブルの他の書き込み操作からの行ロックが非常に多い可能性があります。これが起こると、PostgreSQLは他のトランザクションが完了してから待つまで何をすべきかを安全に知ることができません。

+0

私はあなたが正しいと思います...私はこの最初のALTER TABLE table_name TRIGGER ALLを無効にすることができます。私はそれがうまくいくはずだと思います。 – SUDARSHAN

+0

あなたがあなたの書き込み中にテーブルに排他的なロックを取得し、誰も書き込むことができない場合は、そうです。 –

関連する問題