Dlaczego w SQL Server skanowanie wstecz klastrowanego indeksu nie może wykorzystywać równoległości?

Czytałem o wewnętrznych elementach SQL Server i każda książka lub blog wspomina o skanowaniu wstecznym.

Wsteczne skanowanie indeksu klastrowego nie może wykorzystywać równoległości

Jedyny post, który coś powiedział, to ten poniżej. W poście podano, że zespół SQL Server nie wdrożył wymaganych optymalizacji dla skanowania wstecz. https://www.itprotoday.com/sql-server/descending-indexes

Ponieważ strony na poziomie liścia są połączone za pomocą podwójnie połączonej listy, nie rozumiem, dlaczego skanowanie wstecz jest inne niż skanowanie do przodu. Wszelkie wyjaśnienia są bardzo mile widziane.

W artykule, o którym mowa, wyraźnie podano, że powód, dla którego skany zamówione wstecz nie zostały zrównoleglone w SQL Server 2008 (od CU6), nie jest techniczny, ale ponieważ klienci nie zażądali tej funkcji, a zespół programistów nie zadał sobie trudu, aby ją wdrożyć.

Uwaga: artykuł został napisany prawie 10 lat temu w kontekście nieobsługiwanej wersji SQL Server 2008. Nastąpiły znaczące zmiany w silniku pamięci i optymalizatorze. To powiedziawszy, nadal widzę plan równoległy dla ASCzapytania i plan szeregowy dla DESCwersji z kwerendy demonstracyjnej artykułu na 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;

Uruchomienie tych samych zapytań w programie SQL 2019 CTP 3.2 pokazuje plan szeregowy dla obu, chyba że zmieniłem zapytanie na WHERE orderid <= 50000, w którym zaobserwowałem to samo zachowanie co SQL Server 2017. Wygląda więc na to, że albo równoległe skanowanie wstecz nie zostało jeszcze zaimplementowane, albo potrzebny jest inny scenariusz, aby to zaobserwować.