PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Come capire un'ANALISI ESPLICATIVA

Sebbene non sia così utile per un piano semplice come questo, http://explain.depesz.com è davvero utile. Vedere http://explain.depesz.com/s/t4fi. Nota la scheda "statistiche" e il menu a discesa "opzioni".

Cose da notare su questo piano:

  • Il conteggio delle righe stimato (183) è ragionevolmente paragonabile al conteggio delle righe effettivo (25). Non è centinaia di volte di più, né lo è 1. Sei più interessato agli ordini di grandezza quando si tratta di stime del numero di righe o problemi "1 vs non 1". (Non hai nemmeno bisogno della precisione "abbastanza vicino per il lavoro del governo" - "abbastanza vicino per la contabilità degli appalti militari"). La stima della selettività e le statistiche sembrano ragionevoli.

  • Utilizza l'indice parziale a due colonne fornito (index scan using index_cars_onsale_on_brand_and_model_name ), quindi corrisponde alla condizione di indice parziale. Puoi vederlo nel Filter: has_auto_gear . Viene visualizzata anche la condizione di ricerca dell'indice.

  • Le prestazioni della query sembrano ragionevoli dato che il conteggio delle righe della tabella significa che l'indice è abbastanza grande, soprattutto perché si trova su due colonne. Le righe corrispondenti saranno sparse, quindi è probabile che ogni riga richieda anche una lettura di pagina separata.

Non vedo niente di sbagliato qui. Questa query probabilmente trarrà grandi vantaggi dalle scansioni solo indice di PostgreSQL 9.2, tuttavia.

È possibile che ci sia un po' di tabella gonfia qui, ma dato l'indice a 2 colonne e il semplice numero di righe il tempo di risposta non è del tutto irragionevole, specialmente per una tabella con 170 (!!) colonne che è probabile che rientrino relativamente poche tuple in ciascuna pagina. Se puoi permetterti un po' di tempo di inattività, prova VACUUM FULL per riorganizzare la tabella e ricostruire l'indice. Questo bloccherà esclusivamente la tabella per un po' di tempo mentre la ricostruisce. Se non puoi permetterti i tempi di inattività, consulta pg_reorg e/o CREATE INDEX CONCURRENTLY e ALTER INDEX ... RENAME TO .

Potresti trovare EXPLAIN (ANALYZE, BUFFERS, VERBOSE) a volte più informativo, in quanto può mostrare accessi al buffer, ecc.

Un'opzione che potrebbe rendere questa query più veloce (sebbene corra il rischio di rallentare in qualche modo altre query) è partizionare la tabella su brand e abilita constraint_exclusion . Vedi partizionamento.