Come visto l’indicizzazione delle Table è piuttosto importante per velocizzare le query. Ma esistono anche degli svantaggi:

1. gli indici rallentano il processo di aggiornamento dei dati
2. aumentano lo spazio richiesto dal db.

E’ conveniente quindi un compromesso e le regole a seguire aiutano a trovarlo:

1. Non aggingere indici su campi che non vengono usati con where condition o join condition.
2. Mettere indici su campi da aggiornare pesantemente può diventare un grosso rallentamente al lavoro.
   1. inoltre: quando si caricano numerosi dati dalle shape è meglio mettere l’indice DOPO averli caricati perchè altrimenti l’indice viene aggiornato DURANTE il caricamente che diventa molto lento.
3. Se esiste una campo che è una chiave meglio è meglio usare un unique o primary index. Questo perchè blocca la ricerca non appena trova una corrispondenza senza perdere tempo ad andare oltre. Inoltre restituisce un errore in caso di erronea immissione di un doppione.
4. Per gli indici spaziali usare un gist index. Un gist sostanzialmente memorizza i i confini delle geometrie ma purtroppo non è molto performante con geometrie molto complesse.

Nel caso si siano frequenti per fare un seempio query sulle geometrie e su il campo towns_town si potrebbero inserire 2 indici come sotto:

CREATE INDEX idx_towns_the_geom ON towns USING gist(the_geom);

CREATE INDEX idx_towns_town ON towns USING btree(town);