Postgres: è questo il modo giusto per creare un indice parziale su una colonna booleana?

Question

Ho la seguente tabella:

CREATE TABLE recipemetadata 
(
    --Lots of columns 
    diet_glutenfree boolean NOT NULL, 
); 

La maggior parte ogni riga verrà impostato su FALSE a meno che qualcuno esce con qualche pazzo dieta priva di glutine nuovo che spazza il Paese.

Devo essere in grado di interrogare molto rapidamente le righe in cui questo valore è true. Ho creato l'indice:

CREATE INDEX IDX_RecipeMetadata_GlutenFree ON RecipeMetadata(diet_glutenfree) WHERE diet_glutenfree; 

E sembra funzionare, ma io non riesco a capire come dire se in effetti è solo indicizzazione righe in cui il valore è true. Voglio assicurarmi che non stia facendo qualcosa di sciocco come l'indicizzazione di qualsiasi riga con qualsiasi valore.

Devo aggiungere un operatore alla clausola WHERE oppure questa sintassi è perfettamente valida? Speriamo che questa non sia una di quelle domande RTFM super facili che verranno downvotate 30 volte.

UPDATE:

Sono andato avanti e ha aggiunto 10.000 righe di RecipeMetadata con valori casuali. Ho quindi fatto un ANALIZZA sul tavolo e un REINDEX solo per essere sicuro. Quando eseguo la query:

select recipeid from RecipeMetadata where diet_glutenfree;

ottengo:

'Seq Scan on recipemetadata (cost=0.00..214.26 rows=5010 width=16)' 
' Filter: diet_glutenfree' 

Quindi, sembra stia facendo una scansione sequenziale sul tavolo anche se solo circa la metà le righe hanno questa bandiera. L'indice viene ignorato.

Se lo faccio:

select recipeid from RecipeMetadata where not diet_glutenfree;

ottengo:

'Seq Scan on recipemetadata (cost=0.00..214.26 rows=5016 width=16)' 
' Filter: (NOT diet_glutenfree)' 

Quindi, non importa cosa, questo indice non è in uso.

Answer 1

Ho confermato che l'indice funziona come previsto.

Ho ricreato i dati casuali, solo questa volta impostato diet_glutenfree su random() > 0.9 quindi c'è solo una probabilità del 10% di un on bit.

Ho quindi ricreato gli indici e riprovato.

SELECT RecipeId from RecipeMetadata where diet_glutenfree; 

Returns:

'Index Scan using idx_recipemetadata_glutenfree on recipemetadata (cost=0.00..135.15 rows=1030 width=16)' 
' Index Cond: (diet_glutenfree = true)' 

E:

SELECT RecipeId from RecipeMetadata where NOT diet_glutenfree; 

Ritorni:

'Seq Scan on recipemetadata (cost=0.00..214.26 rows=8996 width=16)' 
' Filter: (NOT diet_glutenfree)' 

Sembra che il mio primo tentativo è stato inquinato dal PG stima che è più veloce per eseguire la scansione l'intero tavolo piuttosto che colpire l'inde x se deve caricare comunque più della metà delle righe.

Tuttavia, penso che vorrei ottenere questi risultati esatti su un indice completo della colonna. C'è un modo per verificare il numero di righe indicizzate in un indice parziale?

UPDATE

L'indice è di circa 40k. Ho creato un indice completo della stessa colonna ed è oltre 200k, quindi sembra che sia decisamente parziale.

Answer 2

un indice su un campo di un bit non ha senso. Per capire le decisioni prese dal progettista, devi pensare in termini di pagine, non in termini di righe.

Per 8K pagine e un (Estinated) rowsize di 80, ci sono 100 righe in ogni pagina. Supponendo una distribuzione casuale, la possibilità che una pagina sia composta solo da righe con un valore true trascurabile, pow (0.5, 100), circa 1e-33, IICC. (E lo stesso per 'falsa' ovviamente) Così per una query su gluten_free == true, ogni pagina deve essere recuperato in ogni caso, e filtrata in seguito. L'utilizzo di un indice causerebbe solo altre pagine (: l'indice) da prelevare.