Question

我有一个复杂的Redshift视图，希望根据可变的日期范围过滤结果。因此，我必须将日期和间隔与CURRENT_DATE进行比较。视图越复杂，查询所需的时间就越长。即使只是在视图中对CURRENT_DATE进行SELECT'ing也会导致速度显着下降。

SELECT CURRENT_DATE FROM complex_view; ==> Average time: ~ 800ms

SELECT CURRENT_DATE FROM less_complex_view; ==> Average time: ~ 400ms

SELECT CURRENT_DATE; ==> Average time: ~ 30ms

与以下内容不同，查询似乎也永远不会被缓存：

SELECT * FROM complex_view; ==> Average time after 4 slow initial calls: ~30 ms

但是，如果我将CURRENT_DATE插入视图中的表中，然后使用该表进行比较，则查询速度很快。

SELECT curr_date_in_table FROM complex_view; ==> Average time: ~ 30ms

问题在于更加复杂（老实说，这项任务是一项日常工作，每天更新一行），并且代码的可维护性更差。为什么在某些情况下仅引用CURRENT_DATE会花费这么多时间？与此very old related post一样，对日期进行硬编码也可以确保快速运行，但是我想使过程自动化。

我对使用EXPLAINs相对较新，但是使用硬编码的当前日期，curr_date_in_table或CURRENT_DATE进行查询之间似乎没有明显的区别。无论运行时间如何，它们的顶级成本都高得离谱。

编辑：Pavel和Jasen似乎是正确的。我创建了一个不变的UDF以在SQL中返回GETDATE（），并且视图上的查询几乎立即运行。它只需要定义一次，因此自动化和代码可维护性又回到了正轨！需要重新定义此基本功能仍然很奇怪。

Answer 1

CURRENT_DATE是一个函数，通常应该非常快（对我来说大约300us）。我真的不知道查询缓慢的真正原因是什么-无法从此处的信息推断出。基本信息是慢速查询的执行计划，而不是这里。

但是我认为可能会有一些优化问题。 CURRENT_DATE虽然看起来不像函数，但它是一个函数（稳定函数）。稳定的功能不会在计划/优化阶段进行评估-因此，当您在查询中使用CURRENT_DATE时，优化器将不知道什么是值，也不会过于激进。

为什么在复杂的Redshift视图中引用CURRENT_DATE会大大降低查询速度？

1 个答案: