我想分享一下我自己在这方面的实验。延迟评估对于优化目的非常有用,对于测试也非常有用。我找不到承诺这种行为的文档,因此这些实验有助于确定当前的行为
不会抛出这些潜在的除以 0 的异常:
select coalesce(1, 1/0), iff(true, 1, 1/0);
这在编写 sql 脚本来验证结果时非常有用。例如,要验证查询是否返回 3 行或引发异常:
select iff(count(*)=3, 1, 1/0)
from (
select * from values(1),(2),(3)
);
让我们看看 Snowflake 是否优化了 CTE,或者无论如何它们是否都会得到评估:
with oh_no as (
select 1/0 oh_no
), fine as (
select 1 fine
)
select *
from fine
;
结果很好:CTE 不会抛出异常,因为不需要它而不会对其进行评估。
这是一个有趣的:
with oh_no as (
select 1/0 oh_no
), fine as (
select 1 fine
)
select *
from (
select * from fine
union all
select * from oh_no
)
limit 1
;
理论上,异常应该被抛出
union
之外。但 Snowflake 看到 LIMIT 1
已被评估,并且它不会浪费时间处理进一步的行。
这意味着相同的查询可能会抛出错误,具体取决于处理行的顺序,并且如果处理初始行数满足查询要求,则不会抛出错误。
正如 @MatBailie 所指出的,所有这些示例都是恒定的,因此可以在执行之前对其进行优化。
让我添加这个示例来测试对实际表的查询结果:
select iff(count(*)=7, 1, 1/0)
from (
select *
from snowflake_sample_data.tpch_sf001.customer
where c_phone like '18-8%'
);
不会抛出异常,因为表中正好有 7 条记录符合条件。好。
对于极端懒惰的例子也是如此,使用实际数据:
with oh_no as (
select 1/0 oh_no
), fine as (
select c_custkey
from snowflake_sample_data.tpch_sf001.customer
where c_phone like '18-8%'
limit 1
)
select *
from (
select * from fine
union all
select * from oh_no
)
limit 1
;
本周我遇到了一些看起来与惰性评估有关的问题,我将在这里与您分享。 基本上,使用 CTE 并逐步过滤它们并不能正常工作。我有一个类似于以下内容的查询:
WITH cte_1 AS (
SELECT field1, field2, field3
FROM table1
WHERE field1 = 'A'
GROUP BY ALL
)
, cte_2 AS (
SELECT field1, field2, field3
FROM table1
WHERE field1 = 'B'
GROUP BY ALL
)
, cte_3 AS (
SELECT * FROM cte_1
UNION ALL
SELECT * FROM cte_2
)
SELECT *
FROM cte_3
WHERE field2 IS NOT NULL
结果的行为类似于首先应用 field2 IS NOT NULL,然后考虑其他过滤器。问题是 cte_1 和 cte_2 中的两个过滤器都会确定 field2 中具有 NULL 值的记录。
我解决了创建带有 cte_3 结果的临时表的问题:
CREATE OR REPLACE TEMPORARY TABLE cte_3 AS
WITH cte_1 AS (
SELECT field1, field2, field3
FROM table1
WHERE field1 = 'A'
GROUP BY ALL
)
, cte_2 AS (
SELECT field1, field2, field3
FROM table1
WHERE field1 = 'B'
GROUP BY ALL
)
SELECT * FROM cte_1
UNION ALL
SELECT * FROM cte_2
;
SELECT *
FROM cte_3
WHERE field2 IS NOT NULL