在我的查询计划中，成本一度爆炸到98位数(~2e97(。首先，它只是上限(10^5..2e97(，最后是两个边界(2e97.2e97(。在这一点上，如果你进一步移动到计划的顶部，成本不会再改变，因此计划变得非常无用。它似乎达到了某种饱和。
我的解释是，查询太复杂了，规划者无法正确评估，成本会上升，直到达到极限(大约为2e97(。
这种解释正确吗关于这种情况是如何发生的，以及如何改进查询/计划，您有更多信息吗？
这里有两个问题。一个是EXPLAIN的实际行为，另一个是错误。
第一个问题是，在Postgres中，EXPLAIN成本在最大程度上是现实的，并且真实地反映了操作所需的实际成本和时间。
这是而不是红移中EXPLAIN的情况。
在Redshift中，成本是任意数字。它们是由开发人员选择的，我认为这是为了相当粗略地控制查询规划器。
我可以看到这种方法没有的优点，也没有无尽的缺点，但它确实存在。
因此，例如，在Redshift扫描表时，每行的成本为1。
对一张表进行排序的成本是1000000000(十亿(，每行加1——所以扫描1b条记录被认为比排序一行更便宜，这太疯狂了。这就是为什么查询计划器有时会出错的原因。
第二个问题是EXPLAIN和DS_DIST_BOTH在成本方面存在缺陷。我相信它使用了一个未初始化的变量，因此其成本大约是宇宙中原子数量的一百万倍。
我确实试图告诉支持。我试了一会儿，然后放弃了。你必须理解Redshift支持的局限性——他们不了解Redshift，而且他们似乎真的不能为自己想太多。我在结束讨论时认为，有人在某个时候告诉他们，计划成本可能会变成一个非常大的数字，从那时起，他们就不可能理解可能会有一个很大的数字，而且实际上可能是错误的。到目前为止，这并不是我放弃尝试让支持理解的唯一错误。