Эффективно ли Redshift (то есть двоичный поиск) находит блок таблицы, который отсортирован по столбцу A для запроса с условием A =?
В качестве примера, пусть имеется таблица T с ~ 500 млн строк, ~ 50 полей, распределенных и отсортированных по полю A. Поле A имеет высокую мощность - поэтому существует ~ 4,5 млн различных значений A с точно таким же количеством строк в T: ~ 100 строк на значение.
Предположим, что кластер красного смещения с одним узлом XL.
Поле A не сжато. Все остальные поля имеют некоторое сжатие формы, как предлагает АНАЛИЗ СЖАТИЯ. Было дано соотношение 1:20 по сравнению с несжатой таблицей.
Учитывая тривиальный запрос:
select avg(B),avg(C) from
(select B,C from T where A = <val>)
После ВАКУУМА и АНАЛИЗА дается следующий план объяснения:
XN Aggregate (cost=1.73..1.73 rows=1 width=8)
-> XN Seq Scan on T (cost=0.00..1.23 rows=99 width=8)
Filter: (A = <val>::numeric)
На выполнение этого запроса уходит 39 секунд.
Главный вопрос: Это ли ожидаемое поведение красного смещения?
Согласно документации на странице Выбор лучшего ключа сортировки:
"Если вы часто выполняете фильтрацию диапазона или фильтрацию равенства для одного столбца, укажите этот столбец в качестве ключа сортировки. Redshift может пропустить чтение целых блоков данных для этого столбца, поскольку он отслеживает минимальные и максимальные значения столбца, хранящиеся в каждый блок и может пропускать блоки, не относящиеся к диапазону предикатов. "
В Выбор ключей сортировки:
«Еще одна оптимизация, которая зависит от отсортированных данных, - это эффективная обработка предикатов с ограниченным диапазоном. Amazon Redshift хранит столбчатые данные в дисковых блоках размером 1 МБ. Минимальные и максимальные значения для каждого блока сохраняются как часть метаданных. Если столбец с ограниченным диапазоном является ключом сортировки, обработчик запросов может использовать минимальные и максимальные значения для быстрого пропуска большого количества блоков во время сканирования таблицы. Например, если в таблице хранятся данные за пять лет, отсортированные по дате, а в запросе указан диапазон дат от одного месяца до 98% дисковых блоков могут быть исключены из сканирования. Если данные не отсортированы, необходимо просканировать больше дисковых блоков (возможно, все). Для получения дополнительной информации об этих оптимизациях см. Выбор ключей распределения. "
Дополнительные вопросы:
Какова сложность вышеупомянутого пропуска сканирования по ключу сортировки? Это линейный (O (n)) или какой-то вариант бинарного поиска (O (logn))?
Если ключ отсортирован - пропускается единственная доступная оптимизация?
Как бы выглядела эта "пропускающая" оптимизация в плане объяснения?
Является ли приведенное выше объяснение наилучшим из возможных для этого запроса?
Какой самый быстрый результат может дать красное смещение при этом сценарии?
Имеет ли vanilla ParAccel другое поведение при таком использовании кейс?
