Amazon Redshift でのクエリプランニング時間が実行時間よりも長く、その理由がわかりません。
簡単な説明
本番環境のロードで排他ロックを使用するクエリでは、ロックの待機時間が長くなるおそれがあります。この増加により、Amazon Redshift でのクエリ計画時間が実際の実行時間よりもはるかに長くなります。ワークロード実行ブレークダウンメトリックをチェックして、クエリプランニング時間が急激に増加していないかどうかを確認してください。ロックを待っているトランザクションが原因で、時間が長くなった可能性があります。
解決策
ロック待ちのトランザクションを検出するには、次の手順を実行します。
-
最初のロック用に新しいセッションを開く:
begin; lock table1;
-
並行して実行される 2 番目のセッションを開き、次のクエリを実行します。
select * from table1 limit 1000;
この 2 番目のセッションのクエリは、AccessSharedLock リクエストを送信します。最初のセッションはすでに AccessExclusiveLock を要求しているため、この 2 番目のクエリはロックにアクセスするまで待つ必要があります。その後、ExclusiveLock でテーブル 1 の他のすべてのオペレ-ションがブロックされます。
-
ワークロード実行ブレークダウンメトリックを確認してください。クエリのプランニング時間が急に増えたら、ロックを待っているトランザクションがあることに間違いはありません。
-
(オプション) ロックを待っているトランザクションが存在する場合は、セッションを手動で終了してロックを解除します。
select pg_terminate_backend(PID);
ロック解除の詳細については、「Amazon Redshift でロックを検出して解放する方法を教えてください」を参照してください。
関連情報
ワークロードパフォーマンスの分析
クエリプランと実行ワークフロー