Используется ли мой ключ сортировки? - PullRequest
Новая
       22

Используется ли мой ключ сортировки?

0 голосов
/ 04 мая 2018

У меня есть таблица со столбцом updated_at, который является ключом сортировки. После запуска VACUUM и ANALYZE для таблицы это план запроса, который я получаю при фильтрации на updated_at: 

EXPLAIN
SELECT *
FROM my_table
WHERE updated_at > '2018-01-01';

QUERY PLAN
XN Seq Scan on my_table  (cost=0.00..0.00 rows=1 width=723)
  Filter: (updated_at > '2018-01-01 00:00:00'::timestamp without time zone)

Насколько я понимаю, механизм выполнения запросов выполняет последовательное сканирование таблицы, несмотря на ключ сортировки, и, следовательно, ключ сортировки ничего не делает?

Ответы [ 2 ]

0 голосов
/ 04 мая 2018

Взгляните на раздел "Анализ сводки запросов" в документации Redshift. Он показывает, как вы можете использовать представление SVL_QUERY_SUMMARY для наблюдения чрезвычайно подробных показателей для каждого выполнения запроса.

Для наиболее эффективного использования ключа сортировки вы должны увидеть столбец rr_scan (сканирование с ограниченным диапазоном), установленный на t, а num_rows_pre_filter должен быть достаточно близко к количеству rows. num_rows_pre_filter - это количество строк, отсканированных с диска до применения фильтра предикатов. NB: «Довольно близко» в этом контексте будет зависеть от ваших конкретных данных. 

SELECT stm,seg,step,TRIM(LEFT(label,30))"label"
      ,rows_pre_filter,rows,avgtime,bytes,is_rrscan 
FROM svl_query_summary 
WHERE query  = 123456
ORDER BY stm ,seg ,step; 

| stm | seg | step |             label             | rows_pre_filter | rows | avgtime | bytes | is_rrscan |
|-----|-----|------|-------------------------------|-----------------|------|---------|-------|-----------|
|   0 |   0 |    0 | scan   tbl=428142 name=my_tbl |          103665 |    6 |   52814 |  1273 | t         |
|   0 |   0 |    1 | project                       |               0 |    6 |   52814 |     0 | f         |
|   0 |   0 |    2 | sort   tbl=303                |               0 |    6 |   52814 |  1288 | f         |
|   1 |   1 |    0 | scan   tbl=303 name=Internal  |               0 |    6 |      74 |  1288 | f         |
|   1 |   1 |    1 | return                        |               0 |    6 |      74 |     0 | f         |
|   1 |   2 |    0 | merge                         |               0 |    0 |     275 |     0 | f         |
|   1 |   2 |    1 | project                       |               0 |    6 |     275 |     0 | f         |
|   1 |   2 |    2 | return                        |               0 |    6 |     275 |  1387 | f         |
0 голосов
/ 04 мая 2018

Последовательное сканирование совершенно нормально в Amazon Redshift, так как он не использует индексы.

Система достаточно умна, чтобы пропускать блоки , которые не содержат желаемых значений, поскольку каждый блок (который содержит данные только для одного столбца) хранит минимум и максимум каждого значения в блоке. Таким образом, блок со всеми датами до 2018-01-01 будет автоматически пропущен.

Это не будет отображаться в плане EXPLAIN, поскольку оно зависит от фактических данных, хранящихся в каждом блоке.

Лучше всего запустить несколько тестов и посмотреть, работает ли он быстро, как и следовало ожидать. Вы бы хотели запустить SET enable_result_cache_for_session TO OFF, чтобы кэширование не влияло на результаты.

Также старайтесь избегать ситуаций, когда КЛЮЧ СОРТИРОВКИ приведен к другому типу. В приведенном выше примере, если столбец представляет собой DATE, но запрос использует его в качестве TIMESTAMP, он может не иметь возможности пропускать блоки, поскольку ему необходимо преобразовать значение после его чтения с диска. Поэтому, это может работать лучше, если там, где используется тот же тип данных.

...