我有一个复杂的Redshift视图，希望根据可变日期范围筛选结果。因此，我必须将日期和间隔与CURRENT_date进行比较。视图越复杂，查询所花费的时间就越长。即使只是在视图中选择"CURRENT_DATE"也会导致显著的速度减慢。
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
这样做的问题是更复杂(一个每天更新一行的cron作业，而该任务实际上是一个非常基本的任务(和更差的代码可维护性。为什么在某些情况下简单地引用CURRENT_DATE会花费这么多时间？与这篇非常古老的相关文章一样，对日期进行硬编码也可以确保快速运行，但我希望自动化这个过程。
我对使用EXPLAIN相对陌生，但使用硬编码的当前日期、curr_date_in_table或current_date进行查询似乎没有明显区别。不管运行时如何，它们都有一些高得离谱的顶层成本。
编辑：帕维尔和杰森似乎是对的。我创建了一个不可变的UDF来返回SQL中的GETDATE((，视图上的查询几乎立即运行。它只需要定义一次，所以自动化和代码可维护性又回到了正轨！仍然很奇怪的是，这个基本功能需要重新定义。
CURRENT_DATE是一个函数，通常应该非常快(在我的comp上大约有300us(。我真的不知道你查询速度慢的真正原因是什么——这是不可能从这里的信息中推断出来的。基本信息是慢速查询的执行计划，但它不在这里。
但我认为可能存在一些优化问题。CURRENT_DATE虽然看起来不像函数，但它是一个函数(稳定函数(。稳定函数在规划/优化阶段不会进行评估，因此当您在查询中使用CURRENT_DATE时，优化器不知道什么是值，也不能过于激进。