В 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. Поэтому кажется, что либо параллельное обратное сканирование еще не реализовано, либо для его наблюдения нужен другой сценарий.