【重新发现PostgreSQL之美】- 50 一粒老鼠屎

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
简介: 大家好,这里是重新发现PostgreSQL之美 - 50 一粒老鼠屎

背景


场景:

  • 在正常业务使用期间, DBA、开发者、分析师在数据库中跑大查询, 某些大表采用了全表扫描.

挑战:

  • 大表的全表扫描会占用buffer pool, 从而将shared buffer中的热数据挤出去, 导致其他业务的SQL变慢, 严重的导致雪崩.

PG 解决方案:

除了全表扫描, PG的bulk - write, vacuum都有类似机制:

bulk - write 16MB ring buffer

COPY FROM command.

CREATE TABLE AS command.

CREATE MATERIALIZED VIEW or REFRESH MATERIALIZED VIEW command.

ALTER TABLE command.

vacuum 256KB ring buffer.

When reading or writing a huge table, PostgreSQL uses a ring buffer rather than the buffer pool. The ring buffer is a small and temporary buffer area. When any condition listed below is met, a ring buffer is allocated to shared memory:

Bulk-reading

When a relation whose size exceeds one-quarter of the buffer pool size (shared_buffers/4) is scanned. In this case, the ring buffer size is 256 KB.

Bulk-writing

When the SQL commands listed below are executed. In this case, the ring buffer size is 16 MB.

COPY FROM command.

CREATE TABLE AS command.

CREATE MATERIALIZED VIEW or REFRESH MATERIALIZED VIEW command.

ALTER TABLE command.

Vacuum-processing

When an autovacuum performs a vacuum processing. In this case, the ring buffer size is 256 KB.

The allocated ring buffer is released immediately after use.

The benefit of the ring buffer is obvious. If a backend process reads a huge table without using a ring buffer, all stored pages in the buffer pool are removed (kicked out); therefore, the cache hit ratio decreases. The ring buffer avoids this issue.

Why the default ring buffer size for bulk-reading and vacuum processing is 256 KB?

Why 256 KB? The answer is explained in the README located under the buffer manager's source directory.

For sequential scans, a 256 KB ring is used. That's small enough to fit in L2 cache, which makes transferring pages from OS cache to shared buffer cache efficient. Even less would often be enough, but the ring must be big enough to accommodate all pages in the scan that are pinned concurrently. (snip)



相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
6月前
|
存储 SQL JSON
PostgreSQL学习研究笔记(一)
PostgreSQL学习研究笔记(一)
|
存储 SQL 关系型数据库
PostgreSQL:分布式数据库简史
好多分布式数据库设计时就考虑到这个趋势,并且有自己的operator来上云,我想未来大部分的分布式数据库都会跑在云上的,这个也是趋势。
PostgreSQL:分布式数据库简史
|
关系型数据库 PostgreSQL
PostgreSQL扫盲教程
PostgreSQL扫盲教程
102 0
PostgreSQL扫盲教程
|
传感器 SQL 监控
【重新发现PostgreSQL之美】- 28 旋转门
大家好,这里是重新发现PostgreSQL之美 - 28 旋转门
|
JSON 关系型数据库 数据库
【重新发现PostgreSQL之美】- 44 摩斯电码
大家好,这里是重新发现PostgreSQL之美 - 44 摩斯电码
|
算法 关系型数据库 PostgreSQL
【重新发现PostgreSQL之美】- 22 黄帝内经
大家好,这里是重新发现PostgreSQL之美 - 22 黄帝内经
|
关系型数据库 数据库 PostgreSQL
【重新发现PostgreSQL之美】- 43 快速破镜重圆
大家好,这里是重新发现PostgreSQL之美 - 43 快速破镜重圆
|
SQL 算法 自动驾驶
【重新发现PostgreSQL之美】- 27 无中生有
大家好,这里是重新发现PostgreSQL之美 - 27 无中生有
|
自然语言处理 算法 关系型数据库
【重新发现PostgreSQL之美 】- 30 打蛇打七寸
大家好,这里是重新发现PostgreSQL之美 - 30 打蛇打七寸
|
安全 Oracle 关系型数据库
【重新发现PostgreSQL之美】- 36 方世玉 安全第一
大家好,这里是重新发现PostgreSQL之美 - 36 方世玉 安全第一