79,341
社区成员




资料显示gaussdb过程在设计如下情况下不能设置为下推处理:
在 GaussDB 中,若存储过程或函数包含以下逻辑,则必须定义为 NOT SHIPPABLE 以确保执行正确性
1、依赖全局临时表或会话级上下文
若操作涉及全局临时表(数据仅存在于 CN 节点会话中)或会话变量(如 SET 设置的参数),则无法下推到 DN 执行。
2、跨 DN 的数据聚合或窗口函数
当逻辑需要全局排序或聚合(如 row_number() OVER (ORDER BY 非分布列))时,因数据分布在多个 DN 上,无法在单节点完成计算。
3、时间敏感操作或非确定性函数
使用 CURRENT_TIMESTAMP、RANDOM() 等函数时,不同 DN 可能返回不一致结果,需统一由 CN 计算。
4、递归查询(WITH RECURSIVE)
递归逻辑需维护中间结果集,无法在分布式节点间协调执行。
CREATE PROCEDURE proc_temp_table()
NOT SHIPPABLE
AS
BEGIN
CREATE GLOBAL TEMPORARY TABLE temp_data (id INT); -- 全局临时表操作
INSERT INTO temp_data VALUES (1);
END;
比如如上过程,实际中的存储过程都是很复杂的逻辑,包括取时间、创建临时表、数据聚合,是否可以这么理解:在定义存储过程时,应该直接定义为not shippable,让gaussdb的CN去决定存储过程中的SQL是否要下推到DN,对于取时间、创建临时表、数据聚合等处理,gaussdb就不下推,别的可以下推的处理就执行下推?不下推的处理我理解发挥不了gaussdb的并行处理优势