Netezza/PureData - 在 HASH JOIN 中选择了错误的分发密钥答案

【问题标题】：Netezza/PureData - Bad distribution key chosen in HASH JOINNetezza/PureData - 在 HASH JOIN 中选择了错误的分发密钥
【发布时间】：2015-03-10 16:46:29
【问题描述】：

我正在使用 Netezza/Pure Data 进行查询。我在 A 和 B 两列上有一个 INNER JOIN（它变成了一个 HASH JOIN）。A 是分布良好的列，B 是分布不好的列。出于某种原因，我的查询计划总是使用 B 而不是 A 作为该 JOIN 的分布键，这会导致巨大的性能问题。

GENERATE STATISTICS 确实有助于缓解此问题，但由于性能限制，在每次查询之前生成统计信息是不可行的。我在批处理运行之前执行此操作，但不在批处理中的每个查询之间执行此操作。

简而言之，源表具有良好的分布，但是当我加入它们时，它们选择了一个错误的分布键（实际上在源中根本没有用作分布列）。

所以我的问题是，在不执行 GENERATE STATISTICS 的情况下，有哪些好的方法可以影响 JOIN 中分配键的选择。我尝试更改源表的分布列，但即使我确保所有偏斜都小于 0.5，也没有太大作用。

【问题讨论】：

查询计划中使用的中间分布通常完全由所选的连接列确定。你能告诉我们这两个表的分布列，然后告诉我们它们在查询中连接的列吗？
另外，请告诉我们计划中显示的中间分布（好的和坏的）。
JOIN列就是上面提到的A列和B列。 A 用作 JOIN 源之一的分布键。 B 永远不会在任何地方用作分发密钥。 A 列分布好，B 列分布不好。问题是在查询计划中选择了 B 列
很抱歉在这里提出问题，但 table_A 真的分布在仅列 A 上吗？ table_B 分布在哪一列（如果有）？
是的，所有的表都只分布在一列上。连接中的一个表仅分布在 A 列上。另一个表分布在不同的列上（不是 B 列）。

标签： performance distribution netezza sql-execution-plan

【解决方案1】：

您可以创建一个临时表并强制分配，以便它们都对齐，这应该加快连接

【讨论】：

【解决方案2】：

解决方法是强制使用穷举计划器。

设置 num_star_planner_rels = X; -- 将 X 设置为非常高。

根据 IBM Netezza 团队的说法，超过 7 个实体（表数）的查询将使用名为“Snowflake”的贪婪查询计划器。在 7 个或更少实体时，它将使用蛮力方法找到最佳计划。

权衡是穷举搜索对于大量实体来说非常昂贵。

【讨论】：