Avaliação do plano de consulta

Você pode usar planos de consulta para identificar candidatos para otimização do estilo de distribuição.

Após tomar as decisões iniciais de design, crie suas tabelas, preencha-as com dados e teste-as. Use um conjunto de dados de teste que seja o mais próximo possível dos dados reais. Meça o tempo de carregamento para usar como linha de base para comparações.

Avalie as consultas que representam as consultas mais caras que você espera executar, especificamente as consultas que usam junções e agregações. Compare os runtimes para várias opções de design. Ao comparar runtimes, não conte a primeira vez que a consulta é executada, porque o primeiro runtime inclui o tempo de compilação.

DS_DIST_NONE

Nenhuma redistribuição é necessária, pois as fatias correspondentes são arranjadas nos nós de computação. Normalmente, você tem apenas uma etapa DS_DIST_NONE, a junção entre a tabela de fatos e uma tabela de dimensão.

DS_DIST_ALL_NONE

Nenhuma redistribuição é necessária, pois a tabela de junção interna usou DISTSTYLE ALL. A tabela completa está localizada em todos os nós.

DS_DIST_INNER

A tabela interna é redistribuída.

DS_DIST_OUTER

A tabela externa é redistribuída.

DS_BCAST_INNER

Uma cópia de toda a tabela interna é transmitida a todos os nós de computação.

DS_DIST_ALL_INNER

Toda a tabela interna é redistribuída a uma única fatia, pois a tabela externa usa DISTSTYLE ALL.

DS_DIST_BOTH

Ambas as tabelas são redistribuídas.

DS_DIST_NONE e DS_DIST_ALL_NONE são bons. Eles indicam que nenhuma distribuição foi necessária para esta etapa, pois todas as junções estão dispostas.

DS_DIST_INNER significa que a etapa provavelmente tem um custo relativamente alto porque a tabela interna está sendo redistribuída para os nós. DS_DIST_INNER indica que a tabela externa já está adequadamente distribuída na chave de junção. Defina a chave de distribuição da tabela interna como a chave de junção para converter isso para DS_DIST_NONE. Em alguns casos, a distribuição da tabela interna na chave de junção não é possível porque a tabela externa não está distribuída na chave de junção. Se esse for o caso, avalie se deseja usar a distribuição ALL para a tabela interna. Se a tabela não for atualizada com frequência ou extensivamente e for grande o suficiente para suportar um alto custo de redistribuição, altere o estilo de distribuição para ALL e teste novamente. A distribuição ALL resulta em maior tempos de carregamento, portanto ao testar novamente, inclua o tempo de carregamento em seus fatores de avaliação.

DS_DIST_ALL_INNER não é bom. Isso significa que toda a tabela interna é redistribuída em uma única fatia, pois a tabela externa usa DISTSTYLE ALL, de forma que uma cópia de toda a tabela externa está localizada em cada nó. Isso resulta em runtime em série ineficaz da junção em um único nó, em vez de tirar proveito do runtime paralelo usando todos os nós. DISTSTYLE ALL é destinado ao uso somente para a tabela de junção interna. Em vez disso, especifique uma chave de distribuição ou use a distribuição uniforme para a tabela externa.

DS_BCAST_INNER e DS_DIST_BOTH não são bons. Geralmente, essas redistribuições ocorrem pois as tabelas não são associadas em suas chaves de distribuição. Se a tabela de fatos ainda não tiver uma chave de distribuição, especifique a coluna de junção como a chave de distribuição para ambas as tabelas. Se a tabela de fatos já tiver uma chave de distribuição em outra coluna, avalie se alterar a chave de distribuição para colocar essa junção melhora a performance geral. Se alterar a chave de distribuição da tabela externa não for uma escolha ideal, você pode obter a colocação especificando DISTSTYLE ALL para a tabela interna.

O seguinte exemplo mostra uma porção de um plano de consulta com os rótulos 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)

Após a alteração das tabelas de dimensões para uso de DISTSTYLE ALL, o plano de consulta para a mesma consulta exibe DS_DIST_ALL_NONE em vez de DS_BCAST_INNER. Além disso, há uma alteração drástica no custo relativo para as etapas da junção. O custo total é 14142.59 comparado ao 3272334142.59 da consulta anterior.

->  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)