Per semplici controlli di uguaglianza (= ), un indice B-Tree su un varchar o text colonna è semplice e la scelta migliore. Sicuramente aiuta le prestazioni molto .
Naturalmente, un indice B-Tree su un semplice integer si comporta meglio. Per cominciare, confrontando il semplice integer valori è un po' più veloce. Ma soprattutto, la performance è anche una funzione della dimensione dell'indice. Una colonna più grande significa meno righe per pagina di dati, significa che è necessario leggere più pagine ...
Dal momento che il HomeAddress non è comunque univoco, non è una buona chiave primaria naturale. Consiglio vivamente di utilizzare una chiave primaria surrogata invece. Un serial colonna
è la scelta più ovvia per questo. Il suo unico scopo è avere una chiave primaria semplice e veloce con cui lavorare.
Se hai altre tabelle che fanno riferimento a detta tabella, questo diventa ancora più efficiente. Invece di duplicare una lunga stringa per la colonna della chiave esterna, sono necessari solo i 4 byte per una colonna intera. E non è necessario aggiungere così tanto aggiornamenti a cascata, dal momento che un indirizzo è destinato a cambiare, mentre un pk surrogato può rimanere lo stesso (ma non è necessario, ovviamente).
La tua tabella potrebbe assomigliare a questa:
CREATE TABLE resident (
resident_id serial PRIMARY KEY
,address text NOT NULL
-- more columns
);
CREATE INDEX resident_adr_idx ON resident(address);
Ciò si traduce in due indici B-Tree. Un indice univoco su resident_id e un semplice indice su address .
Ulteriori informazioni sugli indici nel manuale
.
Postgres offre molte opzioni, ma non te ne servono altre per questo semplice caso.
