Documentazione di PostgreSQL 9.0 > Il linguaggio SQL > Indici > Controllare l'utilizzo dell'indice
PrecedenteClassi operatore e famiglie di operatoriFull Text SearchSuccessivo

11.10. Controllare l'utilizzo dell'indice

Anche se in PostgreSQL™ gli indici non richiedono manutenzione o messa a punto, è comunque importante controllare quali indici vengono realmente usati nei cicli di lavoro delle query. L'esame di utilizzo degli indici per una singola query viene fatto con il comando ???; la sua applicazione per questo scopo è illustrata in Sezione 14.1, «Usare EXPLAIN». È anche possibile raggruppare statistiche complessive circa l'utilizzo degli indici in un server in funzione, come descritto in Sezione 27.2, «The Statistics Collector».

È difficile formulare una procedura generale per determinare quali indici impostare. Ci sono un certo numero di casi tipici che sono stati mostrati negli esempi illustrati nelle sezioni precedenti. Nella maggior parte dei casi sarà necessaria molta sperimentazione. Il resto di questa sezione fornisce un certo numero di consigli per questo:

  • Eseguire sempre ANALYZE(7) prima. Questo comando raccoglie le statistiche circa la distribuzione dei valori nelle tabelle. Questa informazione è richiesta per calcolare il numero di righe restituite da una query, che sono necessarie al planner per assegnare costi realistici per ogni possibile queryplan. In assenza di reali statistiche, vengono assunti valori predefiniti, che sono quasi certamente inaccurati. Esaminare l'utilizzo dell'indice in una applicazione senza aver utilizzato ANALYZE è perciò una causa persa. Vedere Sezione 23.1.3, «Updating Planner Statistics» e Sezione 23.1.5, «The Autovacuum Daemon» per maggiori informazioni.

  • Nelle sperimentazioni utilizzare dati reali. Utilizzare dati di prova per l'impostazione degli indici vi dirà solo di quali indici avrete bisogno per i dati di prova e nient'altro.

    È particolarmente disastroso usare insiemi di dati di prova molto ridotti. Mentre selezionare di 1000 righe da 100000 righe può essere un candidato per un indice, la selezione di 1 riga da 100 righe potrà difficilmente esserlo, perchè le 100 righe entreranno probabilmente in una singola pagina di disco, e non esiste un piano che può girare recuperando sequenzialmente 1 pagina di disco.

    Fare inoltre attenzione quando si selezionano i dati di prova, il cui utilizzo è spesso inevitabile quando l'applicazione non è in produzione. Valori molto simili, completamente casuali, o inseriti in modo ordinato daranno alle statistiche una indicazione diversa rispetto alla distribuzione che i dati avrebbero avuto in realtà.

  • When indexes are not used, it can be useful for testing to force their use. There are run-time parameters that can turn off various plan types (see Sezione 18.6.1, «Planner Method Configuration»). For instance, turning off sequential scans (enable_seqscan) and nested-loop joins (enable_nestloop), which are the most basic plans, will force the system to use a different plan. If the system still chooses a sequential scan or nested-loop join then there is probably a more fundamental reason why the index is not being used; for example, the query condition does not match the index. (What kind of query can use what kind of index is explained in the previous sections.) Quando gli indici non sono usati, può essere utile per i test provare a forzare il loro utilizzo. Ci sono parametri che in fase di esecuzione possono bloccare diversi tipi di piani (consultare Sezione 18.6.1, «Planner Method Configuration»). Per esempio, escludendo la scansione sequenziale (enable_seqscan) e le join nested-loop (enable_nestloop), che sono i piani fondamentali, si forzerà il sistema ad utilizzare un piano differente. Se il sistema sceglie tuttavia una scansione sequenziale o una join nested-loop ci sarà probabilmente una diversa ragione per cui l'indice non viene usato; Per esempio, se la condizione della query non uguaglia l'indice. (Che tipo di query può utilizzare un certo tipo di indice è spiegato nelle sezioni precedenti).

  • Se forzando l'uso dell'indice esso viene utilizzato, ci sono due possibilità: o il sistema ha ragione e l'utilizzo dell'indice è davvero inappropriato, oppure i costi stimati dal queryplan non riflettono la realtà. Si dovrebbe misurare il tempo della query con e senza l'indici. Il comando EXPLAIN ANALYZE potrebbe quì essere utile.

  • [Nota]

    Nota

    Nota per il revisore: oddio....

    Se risulta che i costi stimati sono sbagliati, ci sono, ancora, due possibilità. Il costo totale viene calcolato dal costo per-riga di ogni periodo di nodo di piano stimato selettivamente dal nodo di piano. I costi stimati per i nodi di piano possono essere modificati tramite parametri durante l'esecuzionevia (descritti in Sezione 18.6.2, «Costanti di costo del planner»). Una valutazione di selettività inesatta è dovuta a insufficienti statistiche. È possibile migliorarla, regolando i parametri di riunione-statistiche (vedere ???).

    Se non si riuscirà ad adeguare il costo in modo più appropriato, potrebbe essere necessario forzare esplicitamente l'utilizzo dell'indice. Si potrebbe anche contattare gli sviluppatori PostgreSQL™ per esaminare il problema.

Documentazione di PostgreSQL 9.0 > Il linguaggio SQL > Indici > Controllare l'utilizzo dell'indice
PrecedenteClassi operatore e famiglie di operatoriFull Text SearchSuccessivo