Redshift — как определить низкоэффективные области в Query?

История: я новичок в Redshift и PostgreSQL и хотел бы знать, как повысить производительность моих запросов. Мне нужна обратная связь с точки зрения времени выполнения, объема используемой памяти или других соответствующих показателей из запросов, которые я выполняю.

Вопрос: существует ли простая команда/метод SQL(?), чтобы иметь (хотя бы приблизительное представление) о том, какие области запроса занимают больше всего времени для выполнения?

Дополнительная информация. Я часто использую Common Table Expressions следующим образом:

WITH level1 as (SELECT Customerid 
                FROM customer_tbl
                WHERE year > 2000), 
level2 as (SELECT level1.Customerid,
                  purchasing_tbl.item,
                  purchasing_tbl.price
           FROM level1
           LEFT JOIN purchasing_tbl
                  ON purchasing_tbl.id = level1.Customerid

Обычно этот тип структуры может иметь более 10 уровней, которые обычно включают в себя гораздо более громоздкие (с точки зрения большего количества объединений, где, например, оконные функции с различными агрегациями).

При попытке повысить производительность было бы полезно знать, например. сколько времени потребовалось для выполнения уровня 10 по сравнению с уровнем 2.

Клиент: я использую DBeaver 5.1.1.


sql amazon-redshift query-performance
person Daniel    schedule 27.07.2018    source источник
comment
В Postgres вы можете использовать explain (analyze) ..., но я думаю, что это недоступно в Redshift.   -  person a_horse_with_no_name    schedule 27.07.2018
comment
Да, EXPLAIN ‹sql› допустим в Redshift. Вот хорошая отправная точка: docs.aws .amazon.com/redshift/latest/dg/c-the-query-plan.html и docs.aws.amazon.com/redshift/latest/dg/r_EXPLAIN.html   -  person Victor Di Leo    schedule 27.07.2018
comment
Еще несколько вариантов для изучения планов запросов — предполагаемых и фактических, включая ВРЕМЯ: docs.aws.amazon.com/redshift/latest/mgmt/ И docs.aws.amazon.com/redshift/latest/dg/ Здесь перечислены некоторые системные представления, которые я также считаю полезными.   -  person Victor Di Leo    schedule 27.07.2018
comment
@VictorDiLeo Кажется, это то, что я ищу! Вы бы не использовали его, например. на level2 в примере и поставить как ответ? Скорее всего, я мог бы отдать вам должное за этот ответ.   -  person Daniel    schedule 27.07.2018
comment
Пара вещей, на которые следует обратить внимание: при красном смещении CTE не материализуются. это просто ярлык для вложения (иногда ctes может быть очень дорогим, если вы не понимаете, что генерируется). а также - убедитесь, что вы запускаете свой sql во второй раз (чтобы избежать подсчета времени компиляции) и не используете кешированный результат в красном смещении.   -  person Jon Scott    schedule 27.07.2018
comment
Отличный момент о CTE. Я вижу, как они используются чаще, без реального понимания того, что они делают и чего они не делают.   -  person Victor Di Leo    schedule 29.07.2018

Ответы (2)


arrow_upward
0
arrow_downward

STL_QUERY — это системное представление в Redshift, содержащее время запроса: https://docs.aws.amazon.com/redshift/latest/dg/r_STL_QUERY.html

выберите starttime, enddtime, * из stl_query, где querytxt = '' упорядочить по starttime desc limit 100 ;

person Victor Di Leo    schedule 27.07.2018

arrow_upward
0
arrow_downward

Есть много способов узнать субоптимальные запросы.

Ниже ссылка предлагает различные шаги, чтобы проверить то же самое.

https://docs.aws.amazon.com/redshift/latest/dg/query-performance-improvement-opportunities.html#suboptimal-data-distribution

Есть несколько утилит, предоставляемых AWS, которые доступны в GIT Hub.

https://github.com/awslabs/amazon-redshift-utils

Оба эти материала очень полезны при настройке запросов.

С уважением, Рама

person Rama krishna    schedule 28.07.2018