Évaluation du plan de requête

Vous pouvez utiliser les plans de requête pour identifier des candidats à l’optimisation du style de distribution.

Après avoir pris vos décisions de conception initiales, créez vos tables, chargez-les avec des données et testez-les. Utilisez un ensemble de données de test aussi proche que possible des données réelles. Mesurez les temps de chargement à utiliser comme référence pour les comparaisons.

Évaluez les requêtes qui sont représentatives des requêtes les plus coûteuses que vous vous attendez à exécuter, en particulier les requêtes qui utilisent des jointures et des agrégations. Comparez les durées d’exécution pour différentes options de conception. Lorsque vous comparez les durées d’exécution, ne comptez pas la première fois que la requête est exécutée, car la première exécution inclut le temps de compilation.

DS_DIST_NONE

Aucun redistribution n’est obligatoire, car les tranches correspondantes sont situées sur les nœuds de calcul. Vous n’avez généralement qu’une seule étape DS_DIST_NONE, la jointure entre la table de faits et une table de dimension.

DS_DIST_ALL_NONE

Aucun redistribution n’est obligatoire, car la table de jointure interne a utilisé DISTSTYLE ALL. La totalité de la table se trouve sur chaque nœud.

DS_DIST_INNER

La table interne est redistribuée.

DS_DIST_OUTER

La table externe est redistribuée.

DS_BCAST_INNER

Une copie de la totalité de la table interne est diffusée à tous les nœuds de calcul.

DS_DIST_ALL_INNER

La totalité de la table interne est redistribué à une seule tranche, car la table externe utilise DISTSTYLE ALL.

DS_DIST_BOTH

Les deux tables sont redistribuées.

DS_DIST_NONE et DS_DIST_ALL_NONE sont corrects. Ils indiquent qu’aucune distribution n’a été requise pour cette étape, car toutes les jointures sont colocalisées.

DS_DIST_INNER signifie que l’étape aura probablement un coût relativement élevé, car la table interne est redistribuée aux nœuds. DS_DIST_INNER indique que la table externe est déjà correctement distribuée sur la clé de jointure. Définissez la clé de distribution de la table interne sur la clé de jointure pour convertir celle-ci en DS_DIST_NONE. Dans certains cas, la distribution de la table interne sur la clé de jointure n’est pas possible parce que la table externe n’est pas distribuée sur la clé de jointure. Si c’est le cas, évaluez s’il faut utiliser la distribution ALL pour la table interne. Si la table n’est pas mise à jour fréquemment ou de manière extensive, et qu’elle est suffisamment grande pour supporter un coût de redistribution élevé, changez le style de distribution à ALL et testez à nouveau. La distribution ALL entraîne des temps de charge supérieurs. Par conséquent, lorsque vous refaites le test, incluez le temps de chargement dans vos facteurs d’évaluation.

DS_DIST_ALL_INNER n’est pas correct. Cela signifie que la totalité de la table interne est redistribué à une seule tranche, car la table externe utilise DISTSTYLE ALL, de sorte qu’une copie de la totalité de la table externe est située sur chaque nœud. Il en découle une exécution en série inefficace de la jointure sur un seul nœud, au lieu de tirer parti de l’exécution en parallèle sur l’ensemble des nœuds. DISTSTYLE ALL est conçu pour être utilisé uniquement pour la table de jointure interne. Au lieu de cela, spécifiez une clé de distribution ou utilisez la distribution uniforme pour la table externe.

DS_BCAST_INNER et DS_DIST_BOTH ne sont pas corrects. En général, ces redistributions surviennent parce que les tables ne sont pas jointes sur leurs clés de distribution. Si la table des faits ne dispose pas déjà d’une clé de distribution, définissez la colonne de jointure comme clé de distribution pour les deux tables. Si la table de faits a déjà une clé de distribution sur une autre colonne, évaluez si le fait de changer la clé de distribution pour colocaliser cette jointure améliore les performances globales. Si la modification de la clé de distribution de la table externe n’est pas un choix optimal, vous pouvez obtenir la collocation en spécifiant DISTSTYLE ALL pour la table interne.

L’exemple suivant illustre une partie d’un plan de requête avec les étiquettes DS_BCAST_INNER et 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)

Après avoir modifié les tables de dimension afin d’utiliser DISTSTYLE ALL, le plan de requête de la même requête affiche DS_DIST_ALL_NONE à la place de DS_BCAST_INNER. De plus, le coût relatif des étapes de la jointure ont considérablement changé. Le coût total est de 14142.59, alors que celui de la requête précédente était de 3272334142.59.

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