Медленный запрос красного смещения с низкой стоимостью и количеством строк - PullRequest
0 голосов
/ 27 августа 2018

У меня есть запрос Redshift, в результате которого генерируется следующий план запроса:

XN HashAggregate  (cost=4.00..4.06 rows=1 width=213)
  ->  XN Hash Join DS_DIST_ALL_NONE  (cost=0.02..3.97 rows=1 width=213)
        ->  XN Hash Join DS_DIST_NONE  (cost=0.00..3.93 rows=1 width=213)
        ->  XN Hash  (cost=0.01..0.01 rows=1 width=8)
              ->  XN Seq Scan on response_entities re  (cost=0.00..1.96 rows=157 width=85)
              ->  XN Hash  (cost=0.00..0.00 rows=1 width=208)
                    ->  XN Seq Scan on response_views rv  (cost=0.00..0.00 rows=1 width=208)
              ->  XN Seq Scan on dim_date dd  (cost=0.00..0.01 rows=1 width=8)

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

Детали выполнения на консоли AWS показывают это:

enter image description here

Я не включаю запрос, потому что не ищу причину, по которой этот конкретный запрос занял 3 секунды. Я продолжаю видеть временные рамки выполнения, похожие на эту, и пытаюсь понять, почему, хотя каждый шаг занимает всего пару миллисекунд, запрос заканчивается гораздо дольше. Другие параллельные запросы не выполняются.

Все это время уходит только на компиляцию запросов? Это ожидается? Я что-то упускаю?

1 Ответ

0 голосов
/ 27 августа 2018

Компиляция запросов - вот, что кажется причиной этого Этот запрос медленный скомпилированный сегмент.

select userid, xid,  pid, query, segment, locus,  
datediff(ms, starttime, endtime) as duration, compile 
from svl_compile 
where query = 26540
order by query, segment;

Более подробную информацию о svl_compile можно найти здесь .

И В этой статье объясняется та же проблема и способы уменьшения количества компиляций (или обходных путей).

...