Чому в SQL Server не можна використовувати паралелізм зворотного сканування кластерного індексу?

Я читав про внутрішні програми SQL Server, і кожна книга або блог згадує про те, як сканується назад.

Зворотне сканування кластерного індексу не може використовувати паралелізм

Єдиний пост, який щось сказав, це цей нижче. У публікації йдеться про те, що команда SQL Server не здійснила необхідних оптимізацій для зворотного сканування. https://www.itprotoday.com/sql-server/descending-indexes

Оскільки сторінки рівня листів пов'язані за допомогою подвійно пов'язаного списку, я не розумію, чому сканування назад відрізняється від сканування вперед. Будь-яке уточнення дуже цінується.

У статті, що згадується, конкретно зазначено, що впорядковані сканування не були паралелізовані у SQL Server 2008 (станом на CU6) не є технічним, але через те, що функцію не вимагали замовники, і команда розробників не покладалася на її реалізацію.

Зауважимо, що стаття була написана майже 10 років тому в контексті непідтримуваної версії SQL Server 2008. У двигуні зберігання даних та оптимізаторі відбулися значні зміни. Однак, я все ще бачу паралельний план ASCзапиту та послідовний план для DESCверсії з демо-запиту статті на SQL Server 2017:

SELECT *
FROM dbo.Orders
WHERE orderid <= 100000
ORDER BY orderdate ASC;

SELECT *
FROM dbo.Orders
WHERE orderid <= 100000
ORDER BY orderdate DESC;

Запуск тих самих запитів під SQL 2019 CTP 3.2 показує послідовний план обох, якщо я не змінив запит на WHERE orderid <= 50000, де потім спостерігав таку саму поведінку, що і SQL Server 2017. Отже, схоже, що або паралельне сканування назад ще не було здійснено або для його дотримання потрібен інший сценарій.