PostgreSQL使用大量内存
当执行包含WITH和1000多UNION的查询时，PostgreSQL版本14或更高版本将使用所有服务器内存，直到进入恢复模式。在使用version 11的测试中，此行为不会发生。
WITH DADOS as (
SELECT
CAST( 37959.0 as NUMERIC(9, 0)) id ,
CAST( 1.0 as NUMERIC(9, 0)) emp,
CAST( 12884.0 as NUMERIC(9, 0)) pro ,
CAST( 7.891097087431E12 as NUMERIC(18, 0)) gtin,
to_timestamp( '2023-03-07 12:48:00' , 'YYYY-MM-DD HH24:MI:SS') data3,
CAST( 0.79 as NUMERIC(18, 8)) preco ,
CAST( 10.0 as NUMERIC(18, 8)) valor1 ,
CAST( 0.0 as NUMERIC(18, 8)) preco,
CAST( 0.0 as NUMERIC(18, 8)) valor3,
CAST( '1' as NUMERIC(1, 0)) flag ,
0,
current_timestamp,
current_timestamp,
CAST( 'USER' as varchar(255)) usr,
to_timestamp( '2023-03-07 23:59:00' , 'YYYY-MM-DD HH24:MI:SS') data1,
CAST( 9.0 as NUMERIC(18, 8)) codigo2,
CAST( 5.0 as NUMERIC(1)) opt,
to_timestamp( '2023-03-07 00:00:00' , 'YYYY-MM-DD HH24:MI:SS') data2,
CAST( '2' as NUMERIC(1)) codigo3
UNION ALL
... over 2k unions all..
SELECT
CAST( 37975.0 as NUMERIC(9, 0)) id ,
CAST( 1.0 as NUMERIC(9, 0)) emp,
CAST( 29121.0 as NUMERIC(9, 0)) pro ,
CAST( 7.896011105178E12 as NUMERIC(18, 0)) gtin,
to_timestamp( '2023-03-07 12:48:00' , 'YYYY-MM-DD HH24:MI:SS') data3,
CAST( 1.98 as NUMERIC(18, 8)) preco ,
CAST( 10.0 as NUMERIC(18, 8)) valor1 ,
CAST( 0.0 as NUMERIC(18, 8)) preco,
CAST( 0.0 as NUMERIC(18, 8)) valor3,
CAST( '1' as NUMERIC(1, 0)) flag ,
0,
current_timestamp,
current_timestamp,
CAST( 'USER' as varchar(255)) usr,
to_timestamp( '2023-03-07 23:59:00' , 'YYYY-MM-DD HH24:MI:SS') data1,
CAST( 9.0 as NUMERIC(18, 8)) codigo2,
CAST( 5.0 as NUMERIC(1)) opt,
to_timestamp( '2023-03-07 00:00:00' , 'YYYY-MM-DD HH24:MI:SS') data2,
CAST( '2' as NUMERIC(1)) codigo3
)
select
*
from
dados回答 1
Database Administration用户
发布于 2023-03-08 19:28:00
关于发生了什么https://www.postgresql.org/message-id/211479.1678300966%40sss.pgh.pa.us的解释
我戳了一下这个。对于像SELECT 0，AS x UNION这样的查询，所有选择1，UNION，ALL选择2 UNION，ALL选择3.UNION ALL选择9999，UNION全部选择10000；可以看到v11和v12之间内存使用量的跳跃。另一方面，如果联合臂不是那么简单，就说创建表dual作为SELECT 1 AS y；选择0 AS x从双重UNION选择1所有从双重UNION选择1所有选择2从双重UNION选择3从dual .UNION都从双重联合中选择9999，从dual中选择10000；这两个分支都是同样糟糕的:-(在规划过程中消耗了大约O(N^2)内存和时间。作者: Tom Lane Date: MO一月28日17:54:10 2019-0500在规划者中，用一个虚拟的RTE代替一个空的子句。这是一种有意的更改，允许空从子句选择在与使用常规FROM子句的选择相同的基础上进行优化。问题是，子查询扁平化(在v11中的第一种查询中根本没有发生)正在消耗大量的资源，当有大量的UNION臂时。好消息是，在头上，这两种查询形式都是快速的，这发生在提交e42e312430279dcd8947846fdfeb4885e3754eac作者: Tom Date:清华12月22日11:02:03 2022-0500在提取大量UNION所有子查询时避免O(N^2)开销。我怀疑我们是否会冒险去修补这个问题，但至少有一个解决方案即将到来。你好，汤姆·莱恩
https://dba.stackexchange.com/questions/324487
复制相似问题
腾讯云开发者
