Оптимизация SQL - план выполнения изменяется на основе ограничительного значения - Почему?

У меня есть таблица ItemValue, полная данных по Серверу SQL 2005, выполняющему в 2000 режим эмуляции, который смотрит что-то как (это - Пользовательская таблица значений):

ID    ItemCode     FieldID   Value
--    ----------   -------   ------
 1    abc123             1   D
 2    abc123             2   287.23
 4    xyz789             1   A
 5    xyz789             2   3782.23
 6    xyz789             3   23
 7    mno456             1   W
 9    mno456             3   45
                                 ... and so on.

FieldID происходит из таблицы ItemField:

ID   FieldNumber   DataFormatID   Description   ...
--   -----------   ------------   -----------
 1             1              1   Weight class
 2             2              4   Cost
 3             3              3   Another made up description
 .             .              x   xxx
 .             .              x   xxx
 .             .              x   xxx
 x             91  (we have 91 user-defined fields)

Поскольку я не могу ВЕРТЕТЬСЯ в 2000 режим, мы застреваем, создавая ужасный запрос с помощью СЛУЧАЕВ и GROUP BY, чтобы заставить данные смотреть, как это должно для некоторых приложений прежней версии, который является:

ItemNumber   Field1   Field2    Field3 .... Field51
----------   ------   -------   ------
    abc123   D        287.23    NULL
    xyz789   A        3782.23   23
    mno456   W        NULL      45

Вы видите, что нам только нужна эта таблица, чтобы показать значениям до 51-го UDF. Вот запрос:

SELECT
    iv.ItemNumber,
    ,MAX(CASE WHEN f.FieldNumber = 1 THEN iv.[Value] ELSE NULL END) [Field1]
    ,MAX(CASE WHEN f.FieldNumber = 2 THEN iv.[Value] ELSE NULL END) [Field2]
    ,MAX(CASE WHEN f.FieldNumber = 3 THEN iv.[Value] ELSE NULL END) [Field3]
        ...
    ,MAX(CASE WHEN f.FieldNumber = 51 THEN iv.[Value] ELSE NULL END) [Field51]
FROM ItemField f
LEFT JOIN ItemValue iv ON f.ID = iv.FieldID
WHERE f.FieldNumber <= 51
GROUP BY iv.ItemNumber

Когда ограничение FieldNumber <= 51, выполнять план идет что-то как:

SELECT <== Computer Scalar <== Stream Aggregate <== Sort (Cost: 70%) <== Hash Match <== (Clustered Index Seek && Table Scan)

и это быстро! Я могу отступить 100,000 + записи приблизительно через секунду, которая удовлетворяет нашим потребностям.

Однако, если у нас было больше UDFs, и я изменяю ограничение на что-либо выше 66 (да, я протестировал их один за другим), или если я удаляю его полностью, я теряю Вид в Плане выполнения, и это заменяется целым набором блоков Параллелизма, которые собирают, повторно делят и распределяют потоки, и вся вещь является медленной (30 секунд даже всего для 1 записи).

FieldNumber имеет кластеризованный, уникальный индекс и является частью составного первичного ключа со столбцом ID (некластерный индекс) в таблице ItemField. Столбцы ID и ItemNumber таблицы ItemValue делают PK, и на столбце ItemNumber существует дополнительный некластерный индекс.

Каково обоснование позади этого? Почему делает изменение моего простого целочисленного ограничительного изменения весь план выполнения?

И если бы Вы до него..., что Вы сделали бы по-другому? Существует обновление SQL, запланированное в течение пары месяцев с этого времени, но я должен был зафиксировать эту проблему перед этим.