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

Question

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

永远不会完成的函数

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 位

Answer 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>