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