Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >POSTGRESQL analyze table 到底做了什么与扩展统计

POSTGRESQL analyze table 到底做了什么与扩展统计

作者头像
AustinDatabases
发布于 2021-06-10 06:58:42
发布于 2021-06-10 06:58:42
3.3K0
举报
文章被收录于专栏:AustinDatabasesAustinDatabases

PostgreSQL 中对表的状态是有单独的命令来进行状态的收集的,到底怎么对表来进行状态的收集,并且都做了什么,我们怎么来依靠这些信息来对查询进行有益的帮助。这些都将在这篇文章里面探讨。

首先我们对PG12 中,关于Analyze 的注释来仔细的阅读一遍

ANALYZE collects statistics about the contents of tables in the database, and stores the results in the pg_statistic system catalog. Subsequently, the query planner uses these statistics to help determine the most efficient execution plans for queries.

Without a table_and_columns list, ANALYZE processes every table and materialized view in the current database that the current user has permission to analyze. With a list, ANALYZE processes only those table(s). It is further possible to give a list of column names for a table, in which case only the statistics for those columns are collected.

分析收集数据库中表中关于内容的状态,并将结果存储到pg_statistic 系统目录中,随后查询执行计划的工作中会利用这些数据来帮助查询更有效率的执行,节省查询时间。Analyze命令对于当前数据库中的每一个表或者物化视图进行分析, 前提是操作的用户必须具有这些表的权限,或者是这个数据库的OWNER,或SUPERUSER. 进一步讲,对于表中的某些列进行状态信息的收集.

并且对于表的分析,中外部的表也是被支持的,但也要看你的外部的表是否支持analyzed命令,部分不支持analyze的外部数据的封装器. 在postgresql 默认的设置中, autovacuum 进程,会自动去分析表,当然您也可以根据ORACLE的经验,来对表定期的进行analyze 命令的执行,来收集表中的数据变化后的状态, 这对于加速查询是十分有帮助的. 可以在比较低的工作时间中去运行analyze来保证统计信息的更新性.

这里需要提及的analyze 需要一个读锁来,此时这个工作可以和其他的工作并行工作。这里的工作包含统计表中大部分的列的值的分布,并且可以通过直方图展示每列值的分布的情况。

对于大表,analyze 会对大表取一个随机的表的内容,而不会傻到对每一个行进行一个扫描.这样做的好处是节省数据判断的时间. 但这样的结果是很可能每次运行ANALYZE会有不同的结果,当然一般这样的变化是细微的. 这样的情况下我们可以提高analyze 的手动的次数,提高整体查询计划的平稳性.

而这些数据到底存到了哪里, pg_statistic, pg_statistic 是存储analyze 命令执行后或者autovacuum 执行后统计的内容存储到了这个表. 这里注意存储的数据的值基本都是近似值.

starelid: starelid 是pg_statistic中关于这条记录是表的oid信息

staattnum: 所属表的列的编号

stainherit : 这个列标明这个列是否包含继承的子列,并且是否被统计,TRUE为统计

stanumber1:是我们这列存储的值的分布情况

stavalues1: 存储列中存储的值的明细

select * from pg_stats; pg_stats 是一个类似于可以提供相关数据库方便人类阅读的VIEW ,实际的数据还是通过pg_statistic 获得的。

对数据库表的状态的收集,一般通过autovacuum来就可以了,对于一些比较重要的业务大表,我们也可以学习类似ORACLE 定期对数据进行统计数据分析的方法来进行。

尤其我们还可以针对特定的字段来进行数据的分析和数据的收集,类似我们有一个比较大的表,并且列比较多拿此时我们对于这个表的某个字段查询时频繁,并且是复杂的,同时这个表的这个列的值还是经常变化的。那么此时我们可以针对这个表的这个列来进行分析。

SELECT relname, relkind, reltuples, relpages FROM pg_class order by reltuples desc;

我们可以看到这个表的数据的行数比较大,并且值的分布也比较广泛,也就说明、并且这个字段是bid ,有此我们可以得到两个信息

1 我们如果对这个表的统计信息进行收集,通过普通的方式来收集统计信息,是通过评估的方式,而不会是完全的方式。

2 我们分析可以对单独的这个bid 字段进行分析

以上是建立在我们的查询的where 条件是带有bid 这个条件的, 反过来我们很多的查询并不是单列查询,查询的条件和语句都比较复杂,例如 group by,

这样的情况下我们需要的统计信息可能就需要更有关系性,也就是GROUP BY 中的字段的之间的关系,通过一个统计信息能进行展示。

那我们可以做什么以下以 pgbench_accounts 中有两个字段 bid和 abalance 那么我们需要对这个表经常的使用group by 语句 ,那我们可以通过以下的方式来给查询提供更有效的查询的统计信息。

create statistics bid_ab (ndistinct) on bid,abalance from pgbench_accounts;

analyze pgbench_accounts;

SELECT stxkeys AS k, stxdndistinct AS nd test-# FROM pg_statistic_ext join pg_statistic_ext_data on (oid = stxoid) test-# WHERE stxname = 'bid_ab';

以上我们其实就建立了一个扩展的统计信息,来帮助某些特殊的查询得到更加准确的统计分析信息。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-06-07,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 AustinDatabases 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
监控采集pg的autovacuum情况
业务正处于高峰期,postgresql 反应很慢,监控显示磁盘IO很高,结果登陆机器发现居然是有大量的vaccum在吃磁盘IO。
保持热爱奔赴山海
2025/05/09
640
PostgreSql 数据库统计信息 why when what
统计信息,没有数据是没有的,但统计信息怎么收集,标准是什么,怎么使用,就值得去看看了。
AustinDatabases
2020/03/12
1.6K0
PostgreSql   数据库统计信息 why when what
Greenplum性能优化之路 --(三)ANALYZE
基于规则的优化器,就是优化器在优化查询计划的时候,是根据预先设置好的规则进行的,这些规则无法灵活改变。举个例子,索引优先于扫描,这是一个规则,优化器在遇到所有可以利用索引的地方,都不会选择扫描。这在多数情况下是正确的,但也不完全如此:
lambgong
2020/08/25
4.3K0
Greenplum性能优化之路 --(三)ANALYZE
Postgresql autovacuum 6 为什么大表不进行autovacuum 的原因 (非事务,复制槽原因)
的确是,最近一直在研究和写autovacuum的事情,但造化弄人,阴沟翻船的事情也是不少预见了,这次就遇到了。(让你前5篇嘚瑟)
AustinDatabases
2021/11/10
9160
Postgresql  autovacuum   6  为什么大表不进行autovacuum 的原因 (非事务,复制槽原因)
Postgresql 压力测试 pgbench 与 准不准
任何数据库都有压力测试的需求,每种数据库的压力测试都是要证明这个数据库本身在某种硬件的情况下,能达到的一种可以承受的工作上的压力。 那么有一个问题压力测试的数据准吗? 其实实际上我个人的回答是, 根本不准,反正我也不怎么信。
AustinDatabases
2021/04/22
1.5K0
Postgresql 压力测试   pgbench  与 准不准
PG中的查询:2.统计--(1)
本节讨论成本优化器的基础:统计。通过示例进行讲解。这里会由很多执行计划,后续会更加详细讨论这些计划如何运行。现在只需要注意每个计划的第一行看到的数字以及行数。这些是行数估计值。
yzsDBA
2022/03/29
1.1K0
PG中的查询:2.统计--(1)
Postgresql 损坏的索引怎么查出来,解决了他
POSTGRESQL 中如果你的表文件有损坏,则在查询中会直接告诉你某些文件缺失,你无法对这个表进行查询,或操作. 如果是索引可能就没有这么的简单了.
AustinDatabases
2021/04/01
1.1K0
PostgreSql Postgresql 监控你说了不算,谁说了算 ? (5 整理的一些脚本)
一写就写到了第五期,有点写连续剧的味道,可能会有第六期,我想是,今天的内容并不是某些工具,其实工具也是根据数据库的原理,通过各种方式获得数据。那怎么通过PG中的系统表来获得数据就是这期的重点。
AustinDatabases
2020/07/16
7210
PostgreSql  Postgresql 监控你说了不算,谁说了算 ? (5  整理的一些脚本)
使用pgbench测试你的数据库性能
老高最近遇到了一些性能问题,排查起来很麻烦,其中一个步骤就是需要确定当前DB的抗压能力,Google后收获很大,所以赶紧和老高一起学习研究如果使用pgbench测试你的数据库性能吧!
老高的技术博客
2022/12/28
6490
PG中的查询:2.统计--(2)
当不同值的数量变得太大而无法将他们全部存储在数组时,系统开始使用直方图表示。直方图使用多个存储桶来存储值。存储桶的数量受相同的default_statistics_target参数限制。每个桶的宽度以这样一种方式选择,即在他们之间均匀分布值(如图上具有大致相同面积的矩形表示)。这种表示使系统能够只存储直方图边界,而不是浪费空间来存储每个桶的频率。直方图不包括MCV列表中的值。边界存储在pg_stats的histogram_bounds字段。任何桶的汇总频率等于1/桶数。
yzsDBA
2022/03/29
7640
PG中的查询:2.统计--(2)
PgSQL技术内幕-Analyze做的那些事-pg_statistic系统表
PgSQL的优化器为一个查询生成一个执行效率相对较高的物理执行计划树。执行效率的高低依赖于代价估算。比如估算查询返回的记录条数、记录宽度等,就可以计算出IO开销;也可以根据要执行的物理操作估算出CPU代价。那么估算依赖的信息来源哪呢?系统表pg_statistic(列级别统计信息)为代价估算提供了关键统计信息。Analyze操作或者vacuum进行了统计信息采集,并将对数据按列进行分析,得到每列的数据分布、最常见值、频率等信息,更新到pg_statistic表。当然还有表级别的统计信息,存储在系统表pg_class:relptuples表示表的总元组数,relpages表示总页面数,等。
yzsDBA
2023/11/13
3230
PgSQL技术内幕-Analyze做的那些事-pg_statistic系统表
Pglog高压下日志瓶颈分析
这两个参数打开后会增加大量的日志写入,一般生产环境上纠结的就是这两个参数了,其他日志参数使用的较少。
mingjie
2022/05/12
2200
Pglog高压下日志瓶颈分析
从零开始学PostgreSQL (五): 日常数据库维护任务
PostgreSQL 数据库的维护是确保数据库高效、可靠运行的关键。维护任务可以分为几个关键的方面,包括常规吸尘(VACUUM)、例行重索引(REINDEX)、日志文件维护等。下面我们将详细探讨这些维护任务:
DBA实战
2024/09/06
2050
从零开始学PostgreSQL (五): 日常数据库维护任务
PostgreSQL 难搞的事系列 --- vacuum 的由来与PG16的命令的改进 (1)
开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题,有需求都可以加群群内有各大数据库行业大咖,CTO,可以解决你的问题。加群请联系 liuaustin3 ,在新加的朋友会分到2群(共1720人左右 1 + 2 + 3 + 4+5) 另欢迎 OpenGauss GAUSSDB的技术人员加入
AustinDatabases
2023/11/17
3680
PostgreSQL  难搞的事系列 --- vacuum 的由来与PG16的命令的改进 (1)
HAWQ技术解析(十一) —— 数据管理
一、基本操作 1. INSERT         在常用的增删改查数据库操作中,HAWQ仅支持INSERT和SELECT两种,不支持UPDATE和DELETE,这主要是因为HDFS是一个只能追加数据而
用户1148526
2018/01/03
2.3K0
Postgresql内部缓存与OS缓存的关系
mysql通常使用odirect使数据绕过OS缓冲区落盘,wal还是使用系统缓冲。这样数据的写盘不会造成系统刷脏抖动。在pgsql中数据是与OS缓冲绑定的,自己没有做字节对齐,也不使用odirect的方式直写设备,社区对数据直写的态度也一直很悲观,原因是之前也做过很多探索,结果都不是很好:
mingjie
2022/05/12
5760
Postgresql内部缓存与OS缓存的关系
PostgreSQL Bgwriter 与 checkpoint 性能 与性能测试
话题的从系统性能优化讲起, 熟悉PG的同学都明白PG大部分的与硬件打交道的功能都通过LINUX来进行,如何让PG 与 LINUX 之间更协调的工作就是一个重点.
AustinDatabases
2021/09/24
1.7K0
PostgreSQL  Bgwriter 与 checkpoint  性能 与性能测试
从Oracle到PostgreSQL:动态性能视图 vs 标准统计视图
从 Oracle 到 PostgreSQL :从 Uptime 到数据库实例运行时间
数据和云
2019/06/11
2K0
PG-Pool-II 读写分离使用体验
设置连接数控制,避免过高的连接导致访问报错,当超出连接数上线后,对后续的访问进行排队等待。
腾讯云数据库 TencentDB
2021/09/03
1.8K0
PG-Pool-II 读写分离使用体验
PostgreSQL 如果想知道表中某个条件查询条件在索引中效率 ?
最近一直在寻找,如何不通过 select count(*) from table where 字段 = ‘值’ 类似这样的语句,大约会产生多少结果行的问题的解决方案。在一些大表存在的数据库,去不断查询某一个值在这个大表里面的行数,一直是不受欢迎的事情,最后找到了一个还算靠谱的方案。
AustinDatabases
2023/09/18
4070
PostgreSQL  如果想知道表中某个条件查询条件在索引中效率 ?
推荐阅读
相关推荐
监控采集pg的autovacuum情况
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档