PostgreSQL多依赖函数连续执行超时/挂起问题排查求助

• 事务上下文累积：默认psql中连续执行的语句会处于同一事务（未手动COMMIT时）。单个函数执行会自动提交，但连续执行时所有操作在一个事务内，表的创建、删除、索引操作的事务日志持续累积，占用更多内存与磁盘IO，拖慢执行速度甚至触发超时。
• 查询计划失效：前一个函数刚创建/修改的表，PostgreSQL统计信息未及时更新，后续函数生成的查询计划可能非最优。比如createB查询tableA时，用了旧统计信息导致执行效率骤降。
• 资源持续高负载：三个函数连续执行会持续占用CPU、内存、IO资源，单个执行时系统有时间释放资源，连续执行则让资源长期处于高负载，可能触发系统层面的资源限制（如内存不足引发频繁换页）。
• 非物化CTE行为异常：函数中使用NOT MATERIALIZED的CTE，在连续事务中，可能因基表刚生成的状态，导致CTE重复扫描基表次数增加，或无法利用缓存，拖慢执行。

• 拆分事务验证：在每个函数调用后手动执行COMMIT，观察是否还会停滞，确认是否为事务上下文问题：

  set statement_timeout as '180s';
  select createA();
  COMMIT;
  select createB();
  COMMIT;
  select createC();
  COMMIT;
  

• 开启详细执行日志：临时设置log_min_duration_statement = 0，记录每个函数内部语句的执行时间与计划，对比单独执行和连续执行的差异，定位慢步骤。
• 监控系统资源：连续执行时实时监控服务器CPU、内存、磁盘IO、交换分区使用率，检查是否存在资源耗尽情况（如内存占满、IO等待过高）。
• 手动更新统计信息：在调用createB前执行ANALYZE tableA;，调用createC前执行ANALYZE tableB;，验证是否因统计信息过时导致查询计划不佳。
• 添加函数内步骤日志：在函数的DROP TABLE、CREATE TABLE、CREATE INDEX前后添加RAISE NOTICE 'Step X completed at %', now();，输出时间戳，定位函数内具体哪个步骤在连续执行时变慢。
• 测试CTE物化影响：将函数中的NOT MATERIALIZED改为MATERIALIZED，或直接去掉CTE合并逻辑到主查询，观察连续执行的表现，确认是否为非物化CTE导致的问题。

内容的提问来源于stack exchange，提问作者BernardL