Оптимизировать большое условие IN для запроса Redshift

Стоит попробовать установить sortkeys (last_seen, phash), поставив last_seen первым.

Причина медлительности может заключаться в том, что ведущей колонкой для ключа сортировки является phash, который выглядит как случайный символ. Как говорится в документации AWS redshift dev, столбцы меток времени должны быть ведущими столбцами для ключа сортировки, если они используются для условий where.

Если последние данные запрашиваются чаще всего, укажите столбец отметки времени в качестве ведущего столбца для ключа сортировки. – Выберите лучший ключ сортировки – Amazon Redshift< /а>

При таком порядке ключа сортировки все столбцы будут отсортированы по last_seen, затем по phash. (Что значит иметь несколько столбцов sortkey?)

Одно замечание: вам нужно воссоздать таблицу, чтобы изменить ключ сортировки. Это поможет вам в этом.

Вы можете попробовать создать временную таблицу/подзапрос:

SELECT DISTINCT t.ret_field
FROM table t
JOIN (
   SELECT '5c8615fa967576019f846b55f11b6e41' AS phash
   UNION ALL 
   SELECT '8719c8caa9740bec10f914fc2434ccfd' AS phash
   UNION ALL
   SELECT '9b657c9f6bf7c5bbd04b5baf94e61dae' AS phash
   -- UNION ALL
) AS sub
   ON t.phash = sub.phash
WHERE t.last_seen BETWEEN '2015-10-01 00:00:00' AND '2015-10-31 23:59:59';

В качестве альтернативы выполните поиск по частям (если оптимизатор запросов объединит их в одну, используйте вспомогательную таблицу для хранения промежуточных результатов):

SELECT ret_field
FROM table
WHERE phash IN (
        '5c8615fa967576019f846b55f11b6e41',
        '8719c8caa9740bec10f914fc2434ccfd',
        '9b657c9f6bf7c5bbd04b5baf94e61dae')
  AND last_seen BETWEEN '2015-10-01 00:00:00' AND '2015-10-31 23:59:59'
UNION
SELECT ret_field
FROM table
WHERE phash IN ( ) -- more hashes)
  AND last_seen BETWEEN '2015-10-01 00:00:00' AND '2015-10-31 23:59:59'
UNION 
-- ...

Если оптимизатор запросов объединит его в один, вы можете попробовать использовать временную таблицу для промежуточных результатов.

ИЗМЕНИТЬ:

SELECT DISTINCT t.ret_field
FROM table t
JOIN (SELECT ... AS phash
      FROM ...
) AS sub
   ON t.phash = sub.phash
WHERE t.last_seen BETWEEN '2015-10-01 00:00:00' AND '2015-10-31 23:59:59';

Вам действительно нужно DISTINCT ? Этот оператор может быть дорогим.

Я бы попробовал использовать LATERAL JOIN. В приведенном ниже запросе в таблице Hashes есть столбец phash — это ваша большая партия хэшей. Это может быть временная таблица, (под)запрос, что угодно.

SELECT DISTINCT T.ret_field
FROM
    Hashes
    INNER JOIN LATERAL
    (
        SELECT table.ret_field
        FROM table
        WHERE
            table.phash = Hashes.phash
            AND table.last_seen BETWEEN '2015-10-01 00:00:00' AND '2015-10-31 23:59:59'
    ) AS T ON true

Вполне вероятно, что оптимизатор реализует LATERAL JOIN как вложенный цикл. Он будет перебирать все строки в Hashes и для каждой строки запускать SELECT FROM table. Внутренний SELECT должен использовать индекс, который у вас есть на (phash, last_seen). На всякий случай включите ret_field в индекс, чтобы сделать его покрывающим индексом: (phash, last_seen, ret_field).

В ответе @Diego есть очень важный момент: вместо того, чтобы помещать в запрос постоянные значения phash, поместите их во временную или постоянную таблицу.

Я хотел бы расширить ответ @Diego и добавить, что важно, чтобы эта таблица с хэшами имела индекс, уникальный индекс.

Итак, создайте таблицу Hashes с одним столбцом phash точно такого же типа, как в вашей основной таблице table.phash. Важно, чтобы типы совпадали. Сделайте этот столбец первичным ключом с уникальным кластеризованным индексом. Сбросьте десятки значений phash в таблицу Hashes.

Тогда запрос становится простым INNER JOIN, а не боковым:

SELECT DISTINCT T.ret_field
FROM
    Hashes
    INNER JOIN table ON table.phash = Hashes.phash
WHERE
    table.last_seen BETWEEN '2015-10-01 00:00:00' AND '2015-10-31 23:59:59'

По-прежнему важно, чтобы table имел индекс на (phash, last_seen, ret_field).

Оптимизатор должен иметь возможность воспользоваться тем фактом, что обе соединенные таблицы отсортированы по столбцу phash и что он уникален в таблице Hashes.

вы можете избавиться от «ИЛИ», вставив нужные данные во временную таблицу и объединив их с вашей фактической таблицей.

Вот пример (я использую CTE, потому что с помощью инструмента, который я использую, трудно зафиксировать план, когда у вас есть более одного оператора SQL, но, если можете, используйте временную таблицу)

select * 
from <my_table>
where checksum in 
(
'd7360f1b600ae9e895e8b38262cee47936fb6ced',
'd1606f795152c73558513909cd59a8bc3ad865a8',
'bb3f6bb3d1a98d35a0f952a53d738ddec5c72c84',
'b2cad5a92575ed3868ac6e405647c2213eea74a5'
)

ПРОТИВ

with foo as
(
    select 'd7360f1b600ae9e895e8b38262cee47936fb6ced' as my_key union
    select 'd1606f795152c73558513909cd59a8bc3ad865a8' union
    select 'bb3f6bb3d1a98d35a0f952a53d738ddec5c72c84' union
    select 'b2cad5a92575ed3868ac6e405647c2213eea74a5'
)
select  * 
from <my_table> r 
     join foo f on r.checksum = F.my_key

и вот план, как вы можете видеть, он выглядит более сложным, но это из-за CTE, он не будет выглядеть так на временной таблице:

Вы пытались использовать объединение для всех значений phash?

Просто так:

SELECT ret_field 
FROM   table 
WHERE  phash = '5c8615fa967576019f846b55f11b6e41' -- 1st phash value
and    last_seen BETWEEN '2015-10-01 00:00:00' AND '2015-10-31 23:59:59'

UNION 

SELECT ret_field 
FROM   table 
WHERE  phash = '8719c8caa9740bec10f914fc2434ccfd' -- 2nd phash value
and    last_seen BETWEEN '2015-10-01 00:00:00' AND '2015-10-31 23:59:59'

UNION 

SELECT ret_field 
FROM   table 
WHERE  phash = '9b657c9f6bf7c5bbd04b5baf94e61dae' -- 3rd phash value
and    last_seen BETWEEN '2015-10-01 00:00:00' AND '2015-10-31 23:59:59'

-- and so on...

UNION 

SELECT ret_field 
FROM   table 
WHERE  phash = 'nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn' -- Nth phash value
and    last_seen BETWEEN '2015-10-01 00:00:00' AND '2015-10-31 23:59:59'