0
大きなテーブル（600m行）で約300行を更新する必要があります。Redshift UPDATEはSeq Scanを非常に遅く使用します
私が使用しているクエリは少しトリッキーです：
UPDATE my_table
SET name = CASE WHEN (event_name in ('event_1', 'event_2', 'event_3'))
THEN 'deleted' ELSE name END
WHERE uid IN ('id_1', 'id_2')
私はこのクエリにEXPLAINを使用しようと私が手：
XN Seq Scan on my_table (cost=0.00..103935.76 rows=4326 width=9838)
Filter: (((uid)::text = 'id_1'::text) OR ((uid)::text = 'id_2'::text))
私は、インターリーブソートキーを持っているし、uidが1でありますこのソートキーに含まれる列の クエリがこのようになっている理由は、実際のコンテキストでは、SETのカラム数（名前とともに）は異なる可能性がありますが、おそらく10を超えないことになります。 基本的な考えは、クロス・ジョインが必要です（更新ルールはカラムに固有ですので、それらを混在させたくありません）。 は、例えば、将来的にはのようなクエリがあるでしょう：とにかく
UPDATE my_table
SET name = CASE WHEN (event_name in ("event_1", "event_2", "event_3")) THEN 'deleted' ELSE name END,
address = CASE WHEN (event_name in ("event_1", "event_4")) THEN 'deleted' ELSE address END
WHERE uid IN ("id_1", "id_2")
、戻って最初のクエリに、それは非常に長い時間（約45分）のために実行され、100％のCPUを取ります。
私も単純なクエリをチェックしてみました：
explain UPDATE my_table SET name = 'deleted' WHERE uid IN ('id_1', 'id_2')
XN Seq Scan on my_table (cost=0.00..103816.80 rows=4326 width=9821)
Filter: (((uid)::text = 'id_1'::text) OR ((uid)::text = 'id_2'::text))
私はどんなアドバイスを聞いて幸せになる、それがより明確にするために、質問に追加することができる他に何かわかりません。
CASE文のWHEREキーワードがエラーを引き起こすため、実際のクエリはかなり異なっている必要があります。そこにサブセレクトはありますか？また、テーブル上のdistkeyは何ですか？ – systemjack
ああ、確かに今修正しました。 –
あなたの質問は私には大丈夫です。私はインタリーブされたソートキーで大したことはなかった。ソートキーの一部ではない列でのフィルタリングは、複合ソートキーとインターリーブされたものを使って、まだ10倍程度向上しています。ソートキー列でのフィルタリングは、さらに優れているはずです。 Redshiftで並べ替えるまで、インターリーブされたキーを使用して諦めました。 – systemjack