Valutazione del piano di query

Puoi utilizzare i piani di query per identificare i candidati per l'ottimizzazione dello stile di distribuzione.

Dopo avere fatto la scelta iniziale, crea le tue tabelle, caricale con i dati e verificale. Utilizza un set di dati per il test che sia più reale possibile. Misura i tempi di caricamento per utilizzarli come riferimento per il confronto.

Valutare le query che sono rappresentative di quelle più costose che verranno eseguite; nello specifico, le query che utilizzano combinazioni e aggregazioni. Confrontare i runtime per le varie opzioni di progettazione. Quando si confrontano i runtime di una query, non tenere in conto il primo runtime della query perché include il tempo di compilazione.

DS_DIST_NONE

Non è necessaria alcuna ridistribuzione, perché le sezioni corrispondenti vengono posizionate sui nodi di calcolo. Solitamente si avrà una sola fase DS_DIST_NONE, la combinazione tra la tabella dei fatti e una tabella dimensionale.

DS_DIST_ALL_NONE

Non è necessaria alcuna ridistribuzione, perché la tabella di combinazione interna utilizza DISTSTYLE ALL. L'intera tabella si trova su ogni nodo.

DS_DIST_INNER

La tabella interna viene ridistribuita.

DS_DIST_OUTER

La tabella esterna viene ridistribuita.

DS_BCAST_INNER

Una copia di tutta la tabella interna viene trasmessa a tutti i nodi di calcolo.

DS_DIST_ALL_INNER

Tutta la tabella interna viene ridistribuita in una singola sezione, perché la tabella esterna utilizza DISTSTYLE ALL.

DS_DIST_BOTH

Entrambe le tabelle vengono ridistribuite.

DS_DIST_NONE e DS_DIST_ALL_NONE vanno bene. Indicano che non è stata necessaria alcuna ridistribuzione per quella fase, perché tutte le combinazioni erano posizionate.

DS_DIST_INNER significa che la fase probabilmente avrà un costo relativamente alto, perché la tabella interna è stata ridistribuita sui nodi. DS_DIST_INNER indica che la tabella esterna è già stata propriamente distribuita sulla chiave di combinazione. Imposta la chiave di distribuzione della tabella interna sulla chiave di combinazione per convertirla in DS_DIST_NONE. In alcuni casi, la distribuzione della tabella interna sulla chiave di combinazione non è possibile, perché la tabella esterna non è distribuita sulla chiave di combinazione. In questo caso, valutare se utilizzare la distribuzione ALL per la tabella interna. Se la tabella non viene aggiornata frequentemente o ampiamente, oltre a essere troppo grande per portare alti costi di ridistribuzione, modificare lo stile di distribuzione su ALL e riprovare. Le clausole di distribuzione ALL incrementano i tempi di caricamento, quindi se esegui nuovi test, includi il tempo di caricamento nei fattori di valutazione.

DS_DIST_ALL_INNER non va bene. Ciò significa che tutta la tabella interna viene ridistribuita in una singola sezione, perché la tabella esterna utilizza DISTSTYLE ALL, in modo che una copia di tutta la tabella esterna venga posizionata su ogni nodo. Questo comporta un'esecuzione seriale inefficiente della combinazione su un singolo nodo, anziché trarre vantaggio dal runtime parallelo che utilizza tutti i nodi. DISTSTYLE ALL dovrebbe essere utilizzata solo per la tabella di combinazione interna. Per la tabella esterna invece, specifica una chiave di distribuzione o utilizza la distribuzione EVEN.

DS_BCAST_INNER e DS_DIST_BOTH non vanno bene. Solitamente queste ridistribuzioni si verificano perché le tabelle non vengono combinate sulle loro chiavi di ridistribuzione. Se la tabella dei fatti non dispone ancora di una chiave di distribuzione, specifica la colonna di combinazione come la chiave di distribuzione per entrambe le tabelle. Se la tabella dei fatti ha già una chiave di distribuzione su un'altra colonna, valutare se la modifica della chiave di distribuzione per collocare questo join migliora le prestazioni complessive. Se la modifica della chiave di distribuzione della tabella esterna non dovesse essere una scelta ottimale, è possibile ottenere la collocazione specificando DISTSTYLE ALL per tutte le tabelle interne.

L'esempio seguente mostra una parte del piano di query con le etichette DS_BCAST_INNER e DS_DIST_NONE.

->  XN Hash Join DS_BCAST_INNER  (cost=112.50..3272334142.59 rows=170771 width=84)
        Hash Cond: ("outer".venueid = "inner".venueid)
        ->  XN Hash Join DS_BCAST_INNER  (cost=109.98..3167290276.71 rows=172456 width=47)
              Hash Cond: ("outer".eventid = "inner".eventid)
              ->  XN Merge Join DS_DIST_NONE  (cost=0.00..6286.47 rows=172456 width=30)
                    Merge Cond: ("outer".listid = "inner".listid)
                    ->  XN Seq Scan on listing  (cost=0.00..1924.97 rows=192497 width=14)
                    ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=24)

Dopo aver modificato la tabella dimensionale per utilizzare DISTSTYLE ALL, il piano di query per la stessa query mostra DS_DIST_ALL_NONE al posto di DS_BCAST_INNER. Inoltre, si verifica un significativo cambiamento in termini di costi per le fasi di combinazione. Il costo totale è 14142.59 confrontato con 3272334142.59 della query precedente.

->  XN Hash Join DS_DIST_ALL_NONE  (cost=112.50..14142.59 rows=170771 width=84)
        Hash Cond: ("outer".venueid = "inner".venueid)
        ->  XN Hash Join DS_DIST_ALL_NONE  (cost=109.98..10276.71 rows=172456 width=47)
              Hash Cond: ("outer".eventid = "inner".eventid)
              ->  XN Merge Join DS_DIST_NONE  (cost=0.00..6286.47 rows=172456 width=30)
                    Merge Cond: ("outer".listid = "inner".listid)
                    ->  XN Seq Scan on listing  (cost=0.00..1924.97 rows=192497 width=14)
                    ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=24)