SQL Server 2016: агрегатный оконный оператор пакетного типа | Разделители, отличные от UNBOUNDED и CURRENT ROW. Продолжение

Говоря об аналогичном запросе к таблице TransactionsCS (column-store), отмечу, что для расчета значения агрегата CumulativeBottom план использует оператор пакетного режима Window Aggregate. Далее он предусматривает вычисление номеров строк с помощью оператора Window Aggregate и выполнение расчета агрегата CumulativeTop в традиционном ускоренном варианте построчного режима. Вот статистические данные, которые я получил по результатам выполнения данного запроса: продолжительность — 34 секунды, процессор — 34 секунды, логические операции считывания — 5К, записи — 0. Обратите внимание: по сравнению с работой в традиционном построчном режиме обработки скорость выполнения запроса в данном случае сократилась вдвое.

Аналогичным образом, если вы адресуете запрос к таблице TransactionsDCS (rowstore + фиктивный индекс columnstore), в соответствии с этим планом вычисление агрегата ComulativeBottom будет выполняться с помощью оператора Window Aggregate, далее число строк будет рассчитываться с помощью оператора Window Aggregate, а расчет агрегата ComulativeTop будет выполняться с помощью традиционных операторов построчного режима в ускоренном варианте. Отличие от предыдущего случая состоит в том, что данные извлекаются из сбалансированного дерева и потому необходимости в явно выраженной сортировке нет. Вот статистические данные по производительности, полученные мною в данном случае: продолжительность — 33 секунды, процессор — 33 секунды, логические операции считывания — 5К, записи — 0. Допустим, вы вычисляете оконную функцию SUM (val) с фреймом ROWS BETWEEN 99 PRECEDING AND 1 PRECEDING. При обращении к таблице Transactions (rowstore) план предусматривает расчет номеров строк и двух ускоренных агрегатов с помощью операторов построчного режима.

При обращении к таблице TransactionsCS (columnstore) план предусматривает расчет номеров строк с помощью оператора Window Aggregate, а вычисление двух агрегатов — с помощью операторов ускоренного построчного режима.

При обращении к таблице TransactionsDCS (данные в представлении rowstore плюс фиктивный индекс columnstore) оптимизатор отдает предпочтение плану, где используется только обработка в построчном режиме, как при работе с запросом к таблице Transactions. При использовании ненакопительного агрегата, такого как MIN и МАХ, с фреймом, который не начинается со спецификации UNBOUNDED PRECEDING (к примеру, с фреймом ROWS BETWEEN 99 PRECEDING AND 1 PRECEDING), оптимизатор не может прибегать к тому способу, в соответствии с которым он вычисляет два агрегата в ускоренном режиме и выполняет окончательный расчет на основании двух первых.

Во время выполнения запроса к таблице Transactions (rowstore) и номер строки, и агрегат вычисляются с помощью операторов построчного режима, а ускоренная оптимизация не используется, поэтому все применимые строки фреймов должны быть записаны в буфер окна. Если запрос адресован к таблице TransactionsCS (columnstore), план предусматривает вычисление номеров строк с помощью оператора Window Aggregate, а вычисление агрегата — с помощью операторов построчного режима.

При выполнении запроса к таблице TransactionsDCS (данные в представлении rowstore плюс фиктивный индекс columnstore) план предполагает расчет и номеров строк, и агрегата с помощью операторов построчного режима — так же, как при обработке запроса к таблице Transactions.