Perché operatore aggregato utilizzato dopo la scansione dell'indice univoca

Ho una tabella con un indice univoco filtrato per valori non annullabili. Nel piano di query viene utilizzato distinto. C'è una ragione per questo?

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  

piano di query:

Questa è una limitazione nota di Query Optimizer di SQL Server. È stato segnalato a Microsoft, ma l'elemento Connect (non più disponibile) è stato chiuso.

Ci sono ulteriori conseguenze di questa limitazione, tra cui alcune di cui ho scritto in Limitazioni dell'ottimizzatore con indici filtrati , il riepilogo è citato di seguito:

Questo post evidenzia due importanti limitazioni dell'ottimizzatore con indici filtrati:

• I predicati di join ridondanti possono essere necessari per abbinare gli indici filtrati
• Gli indici univoci filtrati non forniscono informazioni sull'unicità all'ottimizzatore

In alcuni casi può essere pratico aggiungere semplicemente i predicati ridondanti a ogni query. L'alternativa è incapsulare i predicati impliciti desiderati in una vista non indicizzata. Il piano di abbinamento hash in questo post è stato molto migliore del piano predefinito, anche se l'ottimizzatore dovrebbe essere in grado di trovare il piano di unione unione leggermente migliore. A volte, potrebbe essere necessario indicizzare la vista e utilizzare i NOEXPANDsuggerimenti (richiesto comunque per le istanze Standard Edition). In altre circostanze ancora, nessuno di questi approcci sarà adatto.