我必须更新大表(600米行)中的约300行,我试图使其更快。Redshift更新使用序列扫描非常缓慢
我使用的查询是有点棘手:
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是一个包括在这个sortkey中的列。 为什么查询看起来像这样的原因是,在真实的上下文中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关键字会导致错误,所以您的实际查询必须相当不同。那里有一个子选择吗?另外,桌子上有什么? – systemjack
啊,确实现在纠正了它。 –
您的查询对我而言看起来不错。我自己并没有很好的交错排序键。在不属于排序关键字的列上进行过滤使用复合排序关键字与交错关键字,我仍然获得了10倍左右的改进。在sortkey列上过滤应该会更好。我们放弃了使用交错密钥,直到Redshift将它们整理出来。 – systemjack