Por que o operador agregado usado após a varredura de índice exclusiva

Eu tenho uma tabela com um índice exclusivo filtrado para valores não anuláveis. No plano de consulta, há o uso de distinto. Existe uma razão para isso?

USE tempdb

CREATE TABLE T1( Id INT NOT NULL  IDENTITY PRIMARY KEY ,F1 INT , F2 INT )
go
CREATE UNIQUE NONCLUSTERED INDEX UK_T1 ON T1 (F1,F2) WHERE F1 IS NOT NULL AND F2 IS NOT NULL 
GO
INSERT INTO  T1(f1,F2) VALUES(1,1),(1,2),(2,1)

SELECT DISTINCT   F1,F2 FROM T1 WHERE F1 IS NOT NULL AND F2 IS NOT NULL 
SELECT  F1,F2 FROM T1 WHERE F1 IS NOT NULL AND F2 IS NOT NULL  

plano de consulta:

Essa é uma limitação conhecida do otimizador de consultas do SQL Server. Foi relatado à Microsoft, mas o item do Connect (não está mais disponível) foi fechado.

Há consequências adicionais dessa limitação, incluindo algumas sobre as quais escrevi em Limitações do otimizador com índices filtrados , o resumo é citado abaixo:

Esta postagem destaca duas importantes limitações do otimizador com índices filtrados:

• Predicados de junção redundantes podem ser necessários para corresponder a índices filtrados
• Os índices exclusivos filtrados não fornecem informações exclusivas para o otimizador

Em alguns casos, pode ser prático simplesmente adicionar os predicados redundantes a cada consulta. A alternativa é encapsular os predicados implícitos desejados em uma visualização não indexada. O plano de correspondência de hash nesta postagem foi muito melhor do que o plano padrão, mesmo que o otimizador possa encontrar o plano de junção de mesclagem um pouco melhor. Às vezes, pode ser necessário indexar a exibição e usar NOEXPANDdicas (necessárias de qualquer maneira para instâncias da Standard Edition). Ainda em outras circunstâncias, nenhuma dessas abordagens será adequada.