Избыточная сортировка для агрегированной сгруппированной по монотонной функции

Я разрабатываю запрос к таблице, содержащей множество точек во временном ряду. Таблица может стать довольно большой, и поэтому я хочу, чтобы запрос эффективно понижал дискретизацию вывода путем усреднения точек за фиксированные интервалы времени. После написания запроса я удивлен тем, как SQL Server (2008) решил выполнить запрос. План выполнения показывает ненужную операцию сортировки, которая станет дорогостоящей по мере роста временного ряда. Вот проблема, сведенная к простому примеру:

CREATE TABLE [dbo].[Example]
(
    [x] FLOAT NOT NULL,
    [y] FLOAT NOT NULL,
    PRIMARY KEY CLUSTERED 
    (
        [x] ASC
    )
);

SELECT FLOOR([x]), AVG([y])
FROM [dbo].[Example]
GROUP BY FLOOR([x]);

Здесь у меня есть пары (x, y), которые уже отсортированы по x (из-за кластеризованного первичного ключа), и я усредняю ​​y для каждого целого числа x ( путем усечения функцией FLOOR ).Я ожидал, что таблица уже отсортирована соответствующим образом для агрегата, поскольку FLOOR является монотонной функцией. К сожалению, SQL Server решает, что эти данные необходимо повторно отсортировать, и вот план выполнения:

SQL Server не должен иметь возможность выполнять потоковую агрегацию для данных, сгруппированных по монотонной функции столбцов, которые уже подходящим образом отсортировано?

Есть ли общий способ переписать такие запросы, чтобы SQL Server видел, что порядок сохраняется?

[Обновление] Я нашел статью на тему Вещи, которые нужны SQL: саргируемость монотонных функций , и, как следует из названия, похоже, что это оптимизация, которую SQL Server еще не выполняет (в большинстве случаев) .

Вот еще более простые запросы к [dbo]. [Пример] , которые демонстрируют суть:

SELECT [x], [y]
FROM [dbo].[Example]
ORDER BY FLOOR([x]) --sort performed in execution plan

SELECT [x], [y]
FROM [dbo].[Example]
ORDER BY 2*[x] --NO sort performed in execution plan

SELECT [x], [y]
FROM [dbo].[Example]
ORDER BY 2*[x]+1 --sort performed in execution plan

При любом сложении или умножении оптимизатор запросов понимает, что данные уже имеют такой же порядок (и это видно при группировке по таким выражениям). Таким образом, кажется, что концепция монотонных функций понимается оптимизатором, но обычно не применяется.

Я сейчас тестирую решение для вычисленных столбцов / индексов, но похоже, что это резко увеличит размер сохраняемых данных, поскольку Мне понадобится несколько индексов, чтобы охватить диапазон возможных интервалов.