在我的查询计划中成本激增至 98 位数字 (~2e97)。首先，它只是上限 (10^5..2e97)，最后是两个边界 (2e97..2e97)。在这一点上，如果您进一步移动到计划的顶部，成本不会再发生变化，因此该计划变得非常无用。它似乎达到了某种饱和度。
我的解释是，查询过于复杂，计划者无法正确评估，并且成本会上升，直到达到极限（大约 2e97）。
这种解释正确吗？您是否有更多关于这是如何发生的信息以及可以采取哪些措施来改进查询/计划？
【问题讨论】：
标签： amazon-redshift sql-execution-plan
这里有两个问题。一个是EXPLAIN的实际行为，另一个是bug。
第一个问题是，在 Postgres 中，EXPLAIN 成本尽可能符合实际情况，并符合操作所需的实际成本和时间。
这不是在 Redshift 中 EXPLAIN 的情况。
在 Redshift 中，成本是任意数字。它们是由开发人员选择的，我认为是为了相当粗略地控制查询计划器。
我可以看到这种方法的没有优点，并且没有尽头的缺点，但确实如此。 （例如，您无法比较查询之间的成本 - 即使是您只是在试验以找到最有效的解决方案的相同基本查询）。
因此，例如，在 Redshift 中扫描一个表的每行成本为 1。
对表进行排序的成本我认为是 1,000,000,000（十亿），加上每行 1 - 因此扫描 1b 条记录被认为比对一行进行排序便宜，这很疯狂。这就是查询计划器有时会出错的原因。
第二个问题是EXPLAIN 和DS_DIST_BOTH 提供的成本存在错误。我相信它使用了一个未初始化的变量，因此其成本大约是宇宙中原子数量的一百万倍。
我确实试图告诉支持。我尝试了一段时间，然后放弃了。您必须了解 Redshift Support 的局限性——他们不了解 Redshift，而且他们似乎真的不能为自己考虑太多。我从讨论中走出来，认为有人在某个时候告诉他们计划成本可能会变得非常大，从那时起，他们就无法理解可能会有一个非常大的数字它实际上可能是错误的。到目前为止，这不是我为了让支持人员理解而放弃的唯一错误。
【讨论】：