Por qué se utiliza el operador agregado después de un escaneo de índice único

Tengo una tabla con un índice único filtrado para valores no anulables. En el plan de consulta hay uso de distintos. ¿Hay alguna razón para esto?

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  

plan de consulta:

Esta es una limitación conocida del optimizador de consultas de SQL Server. Se ha informado a Microsoft, pero el elemento Conectar (ya no está disponible) se cerró No se solucionará.

Hay consecuencias adicionales de esta limitación, incluidas algunas sobre las que escribí en Limitaciones del optimizador con índices filtrados , el resumen se cita a continuación:

Esta publicación destaca dos limitaciones importantes del optimizador con índices filtrados:

• Los predicados de unión redundantes pueden ser necesarios para que coincidan los índices filtrados
• Los índices únicos filtrados no proporcionan información de unicidad al optimizador

En algunos casos, puede ser práctico simplemente agregar los predicados redundantes a cada consulta. La alternativa es encapsular los predicados implícitos deseados en una vista no indexada. El plan de coincidencia de hash en esta publicación fue mucho mejor que el plan predeterminado, a pesar de que el optimizador debería poder encontrar el plan de combinación de combinación ligeramente mejor. A veces, es posible que deba indexar la vista y usarNOEXPAND sugerencias (de todos modos, se requiere para las instancias de Standard Edition). En otras circunstancias, ninguno de estos enfoques será adecuado.