【PostgreSQL17新特性之-冗余IS [NOT] NULL限定符的处理优化】

2024-05-31 13:36

本文主要是介绍【PostgreSQL17新特性之-冗余IS [NOT] NULL限定符的处理优化】,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

在执行一个带有IS NOT NULL或者NOT NULL的SQL的时候,通常会对表的每一行,都会进行检查以确保列为空/不为空,这是符合常理的。
但是如果本身这个列上有非空(NOT NULL)约束,再次检查就会浪费资源。甚至有时候走索引,但是还需要回表扫描整个表去确认是否满足NULL的条件,这个时候明显是不太合理的。

在PostgreSQL16版本及以前,就算原本的列上有非空索引,查询条件带有NULL和NOT NULL,也感知不到,依然会去扫描表去评估,增加额外的计划和执行的开销。

postgres<16.1>(ConnAs[postgres]:PID[4639] 2024-05-29/12:02:51)=# create table t1 as select * from pg_class;
SELECT 494
postgres<16.1>(ConnAs[postgres]:PID[4639] 2024-05-29/12:02:55)=#  alter table t1 alter COLUMN oid set not null;
ALTER TABLE
postgres<16.1>(ConnAs[postgres]:PID[4639] 2024-05-29/12:09:59)=# \d t1Table "public.t1"
+---------------------+--------------+-----------+----------+---------+
|       Column        |     Type     | Collation | Nullable | Default |
+---------------------+--------------+-----------+----------+---------+
| oid                 | oid          |           | not null |         |
| relname             | name         |           |          |         |
| relnamespace        | oid          |           |          |         |
| reltype             | oid          |           |          |         |
| reloftype           | oid          |           |          |         |
| relowner            | oid          |           |          |         |
| relam               | oid          |           |          |         |
| relfilenode         | oid          |           |          |         |
| reltablespace       | oid          |           |          |         |
... ...postgres<16.1>(ConnAs[postgres]:PID[4639] 2024-05-29/12:10:05)=#  explain (costs off) select * from t1 where oid IS NULL;
+-------------------------+
|       QUERY PLAN        |
+-------------------------+
| Seq Scan on t1          |
|   Filter: (oid IS NULL) |
+-------------------------+
(2 rows)postgres<16.1>(ConnAs[postgres]:PID[4639] 2024-05-29/12:11:03)=#  explain (costs off) select * from t1 where oid IS NOT NULL;
+-----------------------------+
|         QUERY PLAN          |
+-----------------------------+
| Seq Scan on t1              |
|   Filter: (oid IS NOT NULL) |
+-----------------------------+
(2 rows)

David Rowley的相关邮件里也强调了:当我们优化Min/Max聚合时,规划器添加的IS NOT NULL qual会使重写的计划忽略NULL,这可能会导致索引选择不佳的问题。特别是那些没有统计数据,让规划器估算的近似选择性的条件,可能会导致较差的索引选择,例如LIMIT 1更倾向于廉价的启动路径。

PostgreSQL: Removing const-false IS NULL quals and redundant IS NOT NULL quals

image.png

在 PostgreSQL17-beta1 中,为了改进IS [NOT] NULL涉及条件时的规划,NOT NULL首先对列进行条件检查。让planner(规划器)检查NOT NULL列,并让planner(规划器)为所有查询删除这些qual(当不需要它们时),而不仅仅是在优化最小/最大聚合时。 并且还检测NOT NULL列上的IS NULL qual,这也有助于自联接删除工作,因为它必须将严格的联接限定符替换为IS NOT NULL限定符,以确保与原始查询等效。

改进后的 PostgreSQL17-beta1 的现象如下所示:

postgres<17beta1>(ConnAs[postgres]:PID[21590] 2024-05-28/15:29:09)=# create table t1 as select * from pg_class;
SELECT 415
postgres<17beta1>(ConnAs[postgres]:PID[21590] 2024-05-28/15:29:26)=# alter table t1 alter COLUMN oid set not null;
ALTER TABLE
postgres<17beta1>(ConnAs[postgres]:PID[21590] 2024-05-28/15:29:20)=# \d t1Table "public.t1"
+---------------------+--------------+-----------+----------+---------+
|       Column        |     Type     | Collation | Nullable | Default |
+---------------------+--------------+-----------+----------+---------+
| oid                 | oid          |           | not null |         |
| relname             | name         |           |          |         |
| relnamespace        | oid          |           |          |         |
| reltype             | oid          |           |          |         |
| reloftype           | oid          |           |          |         |
| relowner            | oid          |           |          |         |
| relam               | oid          |           |          |         |
| relfilenode         | oid          |           |          |         |
| reltablespace       | oid          |           |          |         |
| relpages            | integer      |           |          |         |
| reltuples           | real         |           |          |         |
| relallvisible       | integer      |           |          |         |
... ...postgres<17beta1>(ConnAs[postgres]:PID[21590] 2024-05-28/15:29:39)=# explain (costs off) select * from t1 where oid IS NULL;
+--------------------------+
|        QUERY PLAN        |
+--------------------------+
| Result                   |
|   One-Time Filter: false |
+--------------------------+
(2 rows)postgres<17beta1>(ConnAs[postgres]:PID[21590] 2024-05-28/15:29:46)=# explain (costs off) select * from t1 where oid IS NOT NULL;
+----------------+
|   QUERY PLAN   |
+----------------+
| Seq Scan on t1 |
+----------------+
(1 row)

参考文档:
1.https://www.postgresql.org/message-id/flat/17540-7aa1855ad5ec18b4@postgresql.org
2.https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b262ad440edecda0b1aba81d967ab560a83acb8a

这篇关于【PostgreSQL17新特性之-冗余IS [NOT] NULL限定符的处理优化】的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1018069

相关文章

Vue3 的 shallowRef 和 shallowReactive:优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉,那么对 shallowRef 和 shallowReactive 是否了解呢? 在编程和数据结构中,“shallow”(浅层)通常指对数据结构的最外层进行操作,而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素,而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层(Shallow) 定义

无人叉车3d激光slam多房间建图定位异常处理方案-墙体画线地图切分方案

墙体画线地图切分方案 针对问题:墙体两侧特征混淆误匹配,导致建图和定位偏差,表现为过门跳变、外月台走歪等 ·解决思路:预期的根治方案IGICP需要较长时间完成上线,先使用切分地图的工程化方案,即墙体两侧切分为不同地图,在某一侧只使用该侧地图进行定位 方案思路 切分原理:切分地图基于关键帧位置,而非点云。 理论基础:光照是直线的,一帧点云必定只能照射到墙的一侧,无法同时照到两侧实践考虑:关

HDFS—存储优化(纠删码)

纠删码原理 HDFS 默认情况下,一个文件有3个副本,这样提高了数据的可靠性,但也带来了2倍的冗余开销。 Hadoop3.x 引入了纠删码,采用计算的方式,可以节省约50%左右的存储空间。 此种方式节约了空间,但是会增加 cpu 的计算。 纠删码策略是给具体一个路径设置。所有往此路径下存储的文件,都会执行此策略。 默认只开启对 RS-6-3-1024k

使用opencv优化图片(画面变清晰)

文章目录 需求影响照片清晰度的因素 实现降噪测试代码 锐化空间锐化Unsharp Masking频率域锐化对比测试 对比度增强常用算法对比测试 需求 对图像进行优化,使其看起来更清晰,同时保持尺寸不变,通常涉及到图像处理技术如锐化、降噪、对比度增强等 影响照片清晰度的因素 影响照片清晰度的因素有很多,主要可以从以下几个方面来分析 1. 拍摄设备 相机传感器:相机传

MySQL高性能优化规范

前言:      笔者最近上班途中突然想丰富下自己的数据库优化技能。于是在查阅了多篇文章后,总结出了这篇! 数据库命令规范 所有数据库对象名称必须使用小写字母并用下划线分割 所有数据库对象名称禁止使用mysql保留关键字(如果表名中包含关键字查询时,需要将其用单引号括起来) 数据库对象的命名要能做到见名识意,并且最后不要超过32个字符 临时库表必须以tmp_为前缀并以日期为后缀,备份

【生成模型系列(初级)】嵌入(Embedding)方程——自然语言处理的数学灵魂【通俗理解】

【通俗理解】嵌入(Embedding)方程——自然语言处理的数学灵魂 关键词提炼 #嵌入方程 #自然语言处理 #词向量 #机器学习 #神经网络 #向量空间模型 #Siri #Google翻译 #AlexNet 第一节:嵌入方程的类比与核心概念【尽可能通俗】 嵌入方程可以被看作是自然语言处理中的“翻译机”,它将文本中的单词或短语转换成计算机能够理解的数学形式,即向量。 正如翻译机将一种语言

SWAP作物生长模型安装教程、数据制备、敏感性分析、气候变化影响、R模型敏感性分析与贝叶斯优化、Fortran源代码分析、气候数据降尺度与变化影响分析

查看原文>>>全流程SWAP农业模型数据制备、敏感性分析及气候变化影响实践技术应用 SWAP模型是由荷兰瓦赫宁根大学开发的先进农作物模型,它综合考虑了土壤-水分-大气以及植被间的相互作用;是一种描述作物生长过程的一种机理性作物生长模型。它不但运用Richard方程,使其能够精确的模拟土壤中水分的运动,而且耦合了WOFOST作物模型使作物的生长描述更为科学。 本文让更多的科研人员和农业工作者

从状态管理到性能优化:全面解析 Android Compose

文章目录 引言一、Android Compose基本概念1.1 什么是Android Compose?1.2 Compose的优势1.3 如何在项目中使用Compose 二、Compose中的状态管理2.1 状态管理的重要性2.2 Compose中的状态和数据流2.3 使用State和MutableState处理状态2.4 通过ViewModel进行状态管理 三、Compose中的列表和滚动

Thymeleaf:生成静态文件及异常处理java.lang.NoClassDefFoundError: ognl/PropertyAccessor

我们需要引入包: <dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-thymeleaf</artifactId></dependency><dependency><groupId>org.springframework</groupId><artifactId>sp

ActiveMQ—消息特性(延迟和定时消息投递)

ActiveMQ消息特性:延迟和定时消息投递(Delay and Schedule Message Delivery) 转自:http://blog.csdn.net/kimmking/article/details/8443872 有时候我们不希望消息马上被broker投递出去,而是想要消息60秒以后发给消费者,或者我们想让消息没隔一定时间投递一次,一共投递指定的次数。。。 类似