Redshift UPDATE использует Seq Scan очень медленно

Question

Мне нужно обновить около 300 строк в большой таблице (600 м строк), и я пытаюсь сделать это быстрее.

Запроса Я использую немного сложнее:

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)) 

У меня есть перемежающаяся SortKey и UID является один столбцов, включенных в этот файл. Причина, по которой запрос выглядит так, заключается в том, что в реальном контексте количество столбцов в 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)) 

Я не знаю, что еще я могу добавить к вопросу, чтобы сделать его более ясным, был бы рад услышать любые советы.

Answer 1

Вы пытались удалить ключ сортировки с чередованием и заменить его простым ключом сортировки на uid или сложным ключом сортировки с uid в качестве первого столбца?

Кроме того, имя uid заставляет меня думать, что вы можете использовать GUID/UUID в качестве значения. Я бы предположил, что это anti-pattern для значения id в Redshift и особенно для ключа сортировки.

Проблемы с GUID/UUID id:

• Не происходит в предсказуемой последовательности
  • Часто вызывает полное последовательное сканирование
  • новые строки всегда нарушать Рода
• Сжатие очень плохо
  • Требует больше места на диска для хранения
  • требуется больше данных для чтения при запросе

Answer 2

обновления в красном смещении удалить, а затем вставить. Redshift по дизайну просто маркирует строки как удаленные и не удаляя их физически (строки-призраки). Явно вакуумное удаление только < имя_таблицы> требуется для освобождения места.

Seq. Сканирование влияет на эти строки призраков. Предложите выполнить команду над командой и проверить производительность запроса позже.