Postgres 查询不会在功能中完成，但如果单独运行它可以工作

Posted 2023-04-19

【中文标题】Postgres 查询不会在功能中完成，但如果单独运行它可以工作

【英文标题】：Postgres query won't finish in function but if run separately it works

【发布时间】：2019-03-01 13:02:12

【问题描述】：

这是我的函数的简化版本，其中包含查询（因此任何变量现在都无用）并且此函数不会完成，但如果我单独运行相同的查询，它会在一秒钟内完成。

永远不会完成的函数

select * from test_function_difference(1);


CREATE OR REPLACE FUNCTION test_function_difference ( 
  p_does_nothing int

)  
RETURNS TABLE(
  t_datum date,
  t_capacity numeric,
  t_used numeric,
  t_category int,
  t_category_name text,  
  t_used_p numeric,
  t_unused_p numeric
)
  VOLATILE
AS $dbvis$

declare
p_sql text := '';
p_execute text := '';
rec record;
begin

p_sql := 
'
 with 
vytizeni as (
  select 
    date_trunc(''day'',mcz.datum)::date as datum ,  
    sum(zd.v_vytizeni)/3600.0 used
  from v_ui_cdc_s5_misto_cas_zdroj_aggregace mcz
  left join (select * , pul_den as den_noc from v_ui_cdc_s5_misto_cas_zdroj_aggregace_zdrobneni) zd on mcz.id = zd.id
  where
    datum between  ''2018-12-31'' and ''2018-12-31''

    and ( zahranicni = 0 or zahranicni is null )
     and den_noc = -1 
  group by 
    date_trunc(''day'',mcz.datum)::date
)
,kapacita as (
  select
    date_trunc(''day'',datum)::date as datum , 
    sum(obsazeni_g)/3600.0 capacity
  from v_ui_cdc_s5_misto_cas_zdroj_aggregace
  where
    datum between  ''2018-12-31'' and ''2018-12-31''

  group by
    date_trunc(''day'',datum)::date 
)
,zdroj as (
  select 
    k.datum,  
    k.capacity,
    v.used,
    -1 category
  from kapacita k 
  join vytizeni v on k.datum = v.datum
)

select
  c.* , 
  kc.nazev::text categeroy_name,
  case when sum(capacity)over(partition by datum) = 0 then 1 else used/sum(capacity)over(partition by datum) end as used_p,
  greatest(1 - case when sum(capacity)over(partition by datum) = 0 then 1 else sum(used)over(partition by datum)/sum(capacity)over(partition by datum) end,0) as unused_p
from  zdroj  c
left join v_ui_cdc_s5_kategorie_cinnosti kc on kc.id = c.category
order by c.datum
';

raise notice '% ' , p_sql;

RETURN QUERY 
execute p_sql;

END;
$dbvis$ LANGUAGE plpgsql

以及我单独运行的查询（在 533 毫秒内完成）

with 
vytizeni as (
  select 
    date_trunc('day',mcz.datum)::date as datum ,  
    sum(zd.v_vytizeni)/3600.0 used
  from v_ui_cdc_s5_misto_cas_zdroj_aggregace mcz
  left join (select * , pul_den as den_noc from v_ui_cdc_s5_misto_cas_zdroj_aggregace_zdrobneni) zd on mcz.id = zd.id
  where
    datum between  '2018-12-31' and '2018-12-31'

    and ( zahranicni = 0 or zahranicni is null )
     and den_noc = -1 
  group by 
    date_trunc('day',mcz.datum)::date
)
,kapacita as (
  select
    date_trunc('day',datum)::date as datum , 
    sum(obsazeni_g)/3600.0 capacity
  from v_ui_cdc_s5_misto_cas_zdroj_aggregace
  where
    datum between  '2018-12-31' and '2018-12-31'

  group by
    date_trunc('day',datum)::date 
)
,zdroj as (
  select 
    k.datum,  
    k.capacity,
    v.used,
    -1 category
  from kapacita k 
  join vytizeni v on k.datum = v.datum
)

select
  c.* , 
  kc.nazev::text categeroy_name,
  case when sum(capacity)over(partition by datum) = 0 then 1 else used/sum(capacity)over(partition by datum) end as used_p,
  greatest(1 - case when sum(capacity)over(partition by datum) = 0 then 1 else sum(used)over(partition by datum)/sum(capacity)over(partition by datum) end,0) as unused_p
from  zdroj  c
left join v_ui_cdc_s5_kategorie_cinnosti kc on kc.id = c.category
order by c.datum

编辑：大约 28 分钟后，我能够从函数中获得结果（我也在周日晚上尝试过，这意味着我拥有整个服务器的资源，因为在正常加载过程中，即使一小时后函数也没有完成）之后我独立运行查询并在 2.1 秒后得到结果这是解释分析

功能：28 分钟 https://explain.depesz.com/s/v9xJ

独立查询：2.1 秒 https://explain.depesz.com/s/aBri

第二次独立运行 430ms https://explain.depesz.com/s/ENva

有趣的说明：如果我将间隔的开始日期编辑为“2018-12-30”或任何其他日期，函数也会完成

意思是

start date = '2018-12-31'
query => finishes under 1 second
function => won't finish
start date = '2018-12-30'
query => finishes under 1 second
function => finishes under 1 second

版本详情：x86_64-pc-linux-gnu 上的 PostgreSQL 10.7，由 gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36) 编译，64 位

【问题讨论】：

从您最初发布的执行计划中，很明显2018-12-30 对行数的估计要高得多。给它一些时间——如果你能产生EXPLAIN (ANALYZE, BUFFERS)的输出，分析问题会更容易。

我可以为单独运行的查询解释分析，但我不能为该函数执行此操作，因为它没有完成（我在运行 45 分钟后停止）

解释分析查询是否单独运行explain.depesz.com/s/Zji6

那么对于长时间运行的查询，普通的EXPLAIN 就足够了。请把这些东西放到问题中，而不是评论。

@LaurenzAlbe 你知道是否有一个存储计划的系统表实际上是为这个问题执行的，我有点怀疑我之前给你的执行计划可能不正确，因为它看起来完全正确与来自单独查询的相同，我只是放入函数'EXPLAIN VERBOSE'并存储到变量并打印

【参考方案1】：

性能差异的原因是函数内部的执行没有使用并行查询，并行执行偶然选择了更好的执行计划。

函数没有标记为并行安全吗？这可能会让一切变得不同。

然而，核心问题是对ui_cdc_s5_misto_cas_zdroj_aggregace 上的扫描结果行数的粗密估计，估计为 1 行而不是 2243 行。

您应该ANALYZE 该表以获得更好的估计。如果仅此一项并不能提高估计值，请尝试在ANALYZE 之前提高default_statistics_target。

如果您需要提高 default_statistics_target 以获得更好的估计，请坚持更改

ALTER TABLE ui_cdc_s5_misto_cas_zdroj_aggregace
   ALTER datum SET STATISTICS <whatever proved useful>

【讨论】：

非常感谢您的分析 1）功能与我在主题中提供的完全一样，我尝试将其修改为并行安全，但我在文档中发现的很少，我把PARALLEL SAFE 在我的编译器接受的函数中 VOLATILE 后面，但运行函数没有区别（日志显示没有并行使用并且函数也没有完成），因此我不确定我是否正确使用了并行安全 2）作为如果并行安全无济于事，我将尝试进行分析

你做对了。不确定它是否有影响。