PostgreSQL offset 原理,及使用注意事项

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: 使用PostgreSQL查询记录时,可以使用offset跳过一些记录,从跳跃点开始取后面的数据。但是这里有一个问题是这样的: postgres=# create or replace function f() returns void as $$ declare begin rais

使用PostgreSQL查询记录时,可以使用offset跳过一些记录,从跳跃点开始取后面的数据。
但是这里有一个问题是这样的:

postgres=# create or replace function f() returns void as 
$$

declare
begin
  raise notice 'called';
end;

$$
 language plpgsql strict volatile;
CREATE FUNCTION

虽然我在这里跳跃了3条记录,但是f()还是在offset的过程中被调用了。
理论上offset跳过的部分是不应该被调用的。

postgres=# select f(),* from ( values(1),(2),(3),(4),(5),(6) ) t(id) offset 3 limit 2;
NOTICE:  called
NOTICE:  called
NOTICE:  called
NOTICE:  called
NOTICE:  called
 f | id 
---+----
   |  4
   |  5
(2 rows)

postgres=# alter function f() stable;
ALTER FUNCTION
postgres=# select f(),* from ( values(1),(2),(3),(4),(5),(6) ) t(id) offset 3 limit 2;
NOTICE:  called
NOTICE:  called
NOTICE:  called
NOTICE:  called
NOTICE:  called
 f | id 
---+----
   |  4
   |  5
(2 rows)

如果使用where条件过滤的行,是绝对不会被调用的。

postgres=# select f(),* from ( values(1),(2),(3),(4),(5),(6) ) t(id) where id=1 limit 5;
NOTICE:  called
 f | id 
---+----
   |  1
(1 row)

另外把函数改成immutable的话,优化器会把这个函数当成一个常量来处理,在生成执行计划前就常量化掉了,所以怎么样都只会调用一次。

postgres=# alter function f() immutable;
ALTER FUNCTION
postgres=# select f(),* from ( values(1),(2),(3),(4),(5),(6) ) t(id) offset 3 limit 2;
NOTICE:  called
 f | id 
---+----
   |  4
   |  5
(2 rows)

那么问题来了,offset 100000 limit 1这样的查询,会造成一个非常严重的问题,被offset的行,每次都会触发函数调用,非常的耗时。
这也给排查性能问题带来了一定的困扰。
这个问题已提交给社区,tom lane给出了回复,因为offset只是将执行结果的一部分过滤掉,不发送给客户端,实际上这些过滤掉的结果是实际发生了计算的。

No, it's not a bug.  OFFSET only results in the skipped tuples not being
delivered to the client; it does not cause them not to be computed.

You could probably do something with a two-level select with the OFFSET
in the sub-select and the volatile function in the top level.

            regards, tom lane  

如果要把计算挪出来,防止多次调用function,可以用子查询。把function 放到最外层,把offset放到子查询里面,这样offset过滤的结果就只会被扫描,而不会被用于计算。 例如

postgres=# alter function f() volatile;
ALTER FUNCTION
postgres=#  select f(),* from (select * from ( values(1),(2),(3),(4),(5),(6) ) t(id) offset 3 limit 2) t;
NOTICE:  called
NOTICE:  called
 f | id 
---+----
   |  4
   |  5
(2 rows)
相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
关系型数据库 数据管理 Go
《PostgreSQL数据分区:原理与实战》
《PostgreSQL数据分区:原理与实战》
201 0
|
6月前
|
缓存 运维 关系型数据库
PostgreSQL技术大讲堂 - 第43讲:流复制原理
PostgreSQL技术大讲堂 - 第43讲:流复制原理
287 2
|
存储 关系型数据库 Go
《深入PostgreSQL的存储引擎:原理与性能》
《深入PostgreSQL的存储引擎:原理与性能》
684 0
|
存储 关系型数据库 数据库
PostgreSQL复制原理及高可用集群
文章来自: 朱贤文 | 成都文武信息技术有限公司 分析
309 1
|
存储 AliSQL 关系型数据库
《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL高可用原理(上)
《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL高可用原理(上)
184 0
|
算法 安全 关系型数据库
《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL高可用原理(中)
《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL高可用原理(中)
159 0
|
存储 缓存 算法
《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL高可用原理(下)
《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL高可用原理(下)
145 0
|
6月前
|
SQL 关系型数据库 数据库
RDS PostgreSQL索引推荐原理及最佳实践
前言很多开发人员都知道索引对于数据库的查询性能至关重要,一个好的索引能使数据库的性能提升成千上万倍。但给数据库加索引是一项相对专业的工作,需要对数据库的运行原理有一定了解。同时,加了索引有没有性能提升、性能提升了多少,这些都是加索引前就想知道的。这项繁杂的工作有没有更好的方案呢?有!就是今天重磅推出...
116 1
RDS PostgreSQL索引推荐原理及最佳实践
|
关系型数据库 分布式数据库 PolarDB
《阿里云产品手册2022-2023 版》——PolarDB for PostgreSQL
《阿里云产品手册2022-2023 版》——PolarDB for PostgreSQL
363 0
|
存储 缓存 关系型数据库

相关产品

  • 云原生数据库 PolarDB
  • 云数据库 RDS PostgreSQL 版