PG statistics

1. Statistics

1.1 Overview of PG statistics

The statistics of pg are mainly divided into two types:

The first type of statistical information is the load indicator "monitoring stats", which collects and updates load indicators in real time through the stat collector process, records some statistical information related to disk blocks, tables, and indexes, and SQL statement execution cost information, etc. .

The second type of statistical information is the data distribution status description "statistics" (Data distribution stats), these statistical information provide the basis for the optimizer to choose the optimal execution plan. There are two ways to collect this type of statistical information:

  • Statistics collection triggered by background process autovacuum lancher
autovacuum : 历史无效数据、冻结事务、xid信息的清理都是由该进程处理。

vacuum : 标准形式的 vacuum 可以和生产数据库操作并行运行(select、insert、update、delete等命令将继续正常工作,但在清理期间你无法使用alter table等命令来更新表的定义)。
vacuum full : vacuum full 类似于表的重建或者说碎片整理,以收回更多磁盘空间但是运行起来更慢,而且vacuum full操作执行期间无法和对此表上的其他操作并发执行。vacuum full不会有后台进程主从触发(只能手动执行)。
  • Manually execute analyze table to manually collect and update statistics

1.2 Load indicator statistics

1.2.1 pg_stat_database indicator meaning

Through pg_stat_database, we can roughly understand the historical operation of a database. A common problem location is:

  • When the value of tup_returned is much larger than tup_fetched, it means that there are more full table scan SQL in the database, combined with pg_stat_statments to locate the specific slow SQL or combined with pg_stat_user_tables to locate the full table scan related table
  • When the value of tup_updated is relatively large, it means that the database is updated frequently. At this time, you need to pay attention to vacuum-related indicators and long transactions. If garbage collection is not performed in time, data expansion will be severe, and table queries will be responded to to a certain extent. effectiveness
  • When the value of temp_files is relatively large, it means that there are many sorting, hashing, or aggregation operations. You can reduce the generation of temporary files by increasing work_mem, and at the same time, the performance of these operations will also be greatly improved.
postgres=# select * from pg_stat_database where datname='db1';
-[ RECORD 1 ]---------+------------------------------
datid                 | 16384                               //数据库oid
datname               | db1                                 //数据库名称
numbackends           | 0                                   //访问当前数据库连接数量
xact_commit           | 35170800                            //该数据库事务提交总量
xact_rollback         | 65                                  //该数据库事务回滚总量
blks_read             | 1047403                             //总磁盘物理读的块数,这里read也可能是从page cache读取,如果这里很高需要结合blk_read_time看是否真的存在很多实际从磁盘读取的情况。
blks_hit              | 152779457                           //在shared_buffer命中的块数
tup_returned          | 218640517                           //对于表来说是全表扫描的行数,对于索引是通过索引方法返回的索引行数,如果这个值数量明显大于tup_fetched,说明当前数据库存在大量全表扫描的情况。
tup_fetched           | 32778249                            //指通过索引返回的行数
tup_inserted          | 18513456                            //插入的行数
tup_updated           | 1755886                             //更新的行数
tup_deleted           | 21499                               //删除的行数
conflicts             | 0                                   //与恢复冲突取消的查询次数(只会在备库上发生)
temp_files            | 20                                  //产生临时文件的数量,如果这个值很高说明work_mem需要调大
temp_bytes            | 334708736                           //临时文件的大小
deadlocks             | 1                                   //死锁的数量,如果这个值很大说明业务逻辑有问题
checksum_failures     |                                     
checksum_last_failure |                                     //
blk_read_time         | 0                                   //数据库中花费在读取文件的时间,这个值较高说明内存较小,需要频繁的从磁盘中读入数据文件
blk_write_time        | 0                                   //数据库中花费在写数据文件的时间,pg中脏页一般都写入page cache,如果这个值较高,说明page cache较小,操作系统的page cache需要更积极的写入。
stats_reset           | 2020-09-24 16:15:54.395313+08       //统计信息重置的时间

1.2.2 pg_stat_user_tables indicator meaning

Through pg_stat_user_tables, we can know which tables in the current database have frequent full table scans and which tables are changed frequently. For tables that change frequently, we can pay more attention to their vacuum-related indicators to avoid table expansion.

db1=# select * from pg_stat_user_tables where relname='t1';
-[ RECORD 1 ]-------+------------------------------
relid               | 17087                             //表的oid
schemaname          | public                            //schema模式
relname             | t1                                //表名称
seq_scan            | 66                                //发生全表扫描次数
seq_tup_read        | 602468                            //全表扫描数据行数,如果这个值很大说明对这个表进行sql很有可能都是全表扫描,需要结合具体的执行计划来看
idx_scan            | 149                               //索引扫描测试
idx_tup_fetch       | 140                               //通过索引扫描返回的行数
n_tup_ins           | 10000                             //插入数据行数
n_tup_upd           | 40                                //更新数据行数
n_tup_del           | 1                                 //删除数据行数
n_tup_hot_upd       | 35                                //hot update的数据行数,这个值与n_tup_upd越接近说明update的性能较好,更新数据时不会更新索引。
n_live_tup          | 9999                              //活着的行数量
n_dead_tup          | 34                                //死亡的行数量,无效数据行
n_mod_since_analyze | 22                                //上次analyze的时间
last_vacuum         |                                   //上次手动vacuum的时间
last_autovacuum     |                                   //上次autovacuum的时间
last_analyze        |                                   //上次手动analyze的时间
last_autoanalyze    | 2020-10-12 14:21:44.597134+08     //上次自动analyze的时间
vacuum_count        | 0                                 //vacuum的次数
autovacuum_count    | 0                                 //autovacuum的次数
analyze_count       | 0                                 //analyze的次数
autoanalyze_count   | 1                                 //自动analyze的次数

2.2.3 pg_stat_user_indexes indicator meaning

Through pg_stat_user_indexes, we can view the usage of the corresponding index, which can help us determine which indexes are basically not used currently, and delete these invalid redundant indexes.

db1=# select * from pg_stat_user_indexes where relname='t1';
-[ RECORD 1 ]-+--------
relid         | 17087               //相关表的oid
indexrelid    | 17094               //索引oid
schemaname    | public              //schema模式
relname       | t1                  //表名
indexrelname  | t1_pkey             //索引名
idx_scan      | 149                 //通过索引扫描的次数,如果这个值很小,说明这个索引很少被用到,可以考虑进行删除
idx_tup_read  | 154                 //通过任意索引方法返回的索引行数
idx_tup_fetch | 140                 //通过索引方法返回的数据行数
-[ RECORD 2 ]-+--------
relid         | 17087
indexrelid    | 17153
schemaname    | public
relname       | t1
indexrelname  | idx_id2
idx_scan      | 0
idx_tup_read  | 0
idx_tup_fetch | 0

2.2.4 pg_statio_user_tables indicator meaning

By querying pg_statio_user_tables, if heap_blks_read and idx_blks_read are high, it means that the shared_buffer is small, and there is a frequent need to read from the disk or page cache to the shared_buffer.

db1=# select * from pg_statio_user_tables where relname='t1';
-[ RECORD 1 ]---+-------
relid           | 17087             //相关表oid
schemaname      | public            //schema模式
relname         | t1                //表名
heap_blks_read  | 54                //指从page cache或者磁盘中读入表的块数
heap_blks_hit   | 13620             //指在shared_buffer中命中表的块数
idx_blks_read   | 16                //指从page cache或者磁盘中读入索引的块数
idx_blks_hit    | 19536             //在shared_buffer中命中的索引的块数
toast_blks_read | 0                 //从page cache或者磁盘中读入toast表的块数
toast_blks_hit  | 0                 //指在shared_buffer中命中toast表的块数
tidx_blks_read  | 0                 //从page cache或者磁盘中读入toast表索引的块数
tidx_blks_hit   | 0                 //指在shared_buffer中命中toast表索引的块数

2.2.5 pg_stat_bgwriter indicator meaning

db1=# select * from pg_stat_bgwriter;
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed     | 9208                        //指超过checkpoint_timeout的时间后触发的检查点
checkpoints_req       | 18                          //指手动触发的检查点或者因为wal文件数量到达max_wal_size大小时也会增加,如果这个值大于checkpoints_timed,说明checkpoint_timeout设置的不合理。
checkpoint_write_time | 1404403                     //指从shared_buffer中write到page cache花费的时间
checkpoint_sync_time  | 980                         //指checkpoint调用fsync将脏数据同步到磁盘花费的时间,如果这个时间很长容易造成IO的抖动,这时候需要增加checkpoint_timeout或者增加checkpoint_completion_target。
buffers_checkpoint    | 19861                       //checkpoint写入的脏块的数量
buffers_clean         | 1868                        //通过bgwriter写入的块的数量
maxwritten_clean      | 0                           //指bgwriter超过bgwriter_lru_maxpages时停止的次数,如果这个值很高说明需要增加bgwriter_lru_maxpages的大小
buffers_backend       | 404509                      //通过backend写入的块数量
buffers_backend_fsync | 0                           //指backend需要fsync的次数
buffers_alloc         | 54296                       //被分配的缓冲区数量
stats_reset           | 2020-09-23 15:14:57.052247+08

2.2.6 pg_stat_replication indicator meaning

pg_stat_replication only displays relevant data in the master-slave architecture. According to the query to the pg_stat_replication table, you can view the current replication mode, replication configuration information, replication site information, etc.

postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 15040                    //负责流复制进程的pid
usesysid         | 16384                    //用户ID
usename          | repl                     //复制用户
application_name | walreceiver              //这是同步复制的通常设置,它可以通过连接字符串传递到master。
client_addr      | 192.168.1.171            //客户端地址
client_hostname  |                          //客户端主机名称,可在postgres.conf中对log_hostname参数设置,启动DNS反向查找
client_port      | 58690                    //客户端用来和WALsender进行通信使用的TPC端口号,如果不本地UNIX套接字被使用了将显示-1。
backend_start    | 2020-09-05 13:42:30.108815+08    //流复制开始时间
backend_xmin     |
state            | streaming                //复制模式
sent_lsn         | 0/3000148                //发送到连接的最后的位点
write_lsn        | 0/3000148                //standby数据库落盘的位点
flush_lsn        | 0/3000148                //standby数据库flush的位点
replay_lsn       | 0/3000148                //standby数据库重放的位点
write_lag        |                          //写延迟间隙
flush_lag        |                          //flush延迟间隙
replay_lag       |                          //重放延迟间隙
sync_priority    | 0                        //复制优先级权重
sync_state       | async                    //同步模式,同步or异步
reply_time       | 2020-09-05 13:49:41.269624+08    //

2.2.7 pg_stat_statement indicator meaning

The pg_stat_statements module provides a means to track all SQL statements executed by the execution statistics server. The module is not enabled by default. If you need to enable it, we need to manually compile and install it, modify the configuration file and restart the database, and manually load the module before use.

1. Manually install and load the pg_stat_statement module

-- 进入pgsql软件的contrib目录下,查看是否有pg_stat_statements相关模块
# pwd
/usr/local/postgresql-12.2/contrib
# ls | grep pg_stat_statements
pg_stat_statements

-- 进入pg_stat_statement模块目录下进行编译安装
# make && make install

-- 检查pg_stat_statement是否安装成功
# cd /usr/local/pgsql/share/extension/
# ll | grep pg_stat_statements
-rw-r--r-- 1 root root  1246 10月 25 15:46 pg_stat_statements--1.0--1.1.sql
-rw-r--r-- 1 root root  1336 10月 25 15:46 pg_stat_statements--1.1--1.2.sql
-rw-r--r-- 1 root root  1454 10月 25 15:46 pg_stat_statements--1.2--1.3.sql
-rw-r--r-- 1 root root   345 10月 25 15:46 pg_stat_statements--1.3--1.4.sql
-rw-r--r-- 1 root root   305 10月 25 15:46 pg_stat_statements--1.4--1.5.sql
-rw-r--r-- 1 root root  1427 10月 25 15:46 pg_stat_statements--1.4.sql
-rw-r--r-- 1 root root   376 10月 25 15:46 pg_stat_statements--1.5--1.6.sql
-rw-r--r-- 1 root root   806 10月 25 15:46 pg_stat_statements--1.6--1.7.sql
-rw-r--r-- 1 root root   191 10月 25 15:46 pg_stat_statements.control
-rw-r--r-- 1 root root   449 10月 25 15:46 pg_stat_statements--unpackaged--1.0.sql

-- 修改配置文件
# vi postgres.conf
shared_preload_libraries='pg_stat_statements,pg_pathman'
pg_stat_statements.max = 10000
pg_stat_statements.track = all

-- 重启数据库
# su - postgres
$ pg_ctl -D /data/pgsql12/data restart

-- 登录数据库,载入pg_stat_statement模块
postgres=# SELECT * FROM pg_available_extensions WHERE name = 'pg_stat_statements';               //查看可用模块
-[ RECORD 1 ]-----+----------------------------------------------------------
name              | pg_stat_statements
default_version   | 1.7
installed_version |
comment           | track execution statistics of all SQL statements executed

postgres=# create extension pg_stat_statements;         //载入模块,载入后pg_stat_statements表可正常使用
CREATE EXTENSION

2. pg_stat_statements indicator meaning

postgres=# select * from  pg_stat_statements limit 1;
-[ RECORD 1 ]-------+------------------------------------------------------------------------
userid              | 10                        //用户id
dbid                | 13547                     //数据库oid
queryid             | 1194713979                //查询id
query               | SELECT * FROM pg_available_extensions WHERE name = 'pg_stat_statements'   //查询SQL
calls               | 1                         //调用次数
total_time          | 53.363875                 //SQL总共执行时间
min_time            | 53.363875                 //SQL最小执行时间
max_time            | 53.363875                 //SQL最大执行时间
mean_time           | 53.363875                 //SQL平均执行时间
stddev_time         | 0                         //SQL花费时间的表中偏差
rows                | 1                         //SQL返回或者影响的行数
shared_blks_hit     | 1                         //SQL在在shared_buffer中命中的块数
shared_blks_read    | 0                         //SQL从page cache或者磁盘中读取的块数
shared_blks_dirtied | 0                         //SQL语句弄脏的shared_buffer的块数
shared_blks_written | 0                         //SQL语句写入的块数
local_blks_hit      | 0                         //临时表中命中的块数
local_blks_read     | 0                         //临时表需要读的块数
local_blks_dirtied  | 0                         //临时表弄脏的块数
local_blks_written  | 0                         //临时表写入的块数
temp_blks_read      | 0                         //从临时文件读取的块数
temp_blks_written   | 0                         //从临时文件写入的数据块数
blk_read_time       | 0                         //从磁盘或者读取花费的时间
blk_write_time      | 0                         //从磁盘写入花费的时间

1.3 Data distribution statistics

1.3.1 pg_stats

By querying pg_stats, you can view the data analysis statistics of each field, similar to the histogram of SQL Server, and provide a basis for the optimizer to choose the best execution plan. pg_stats can only be accessed by the administrator account.

db1=# select * from pg_stats where tablename='t1' limit 1;
-[ RECORD 1 ]----------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
schemaname             | public         //schema模式
tablename              | t1             //表名
attname                | id             //列名
inherited              | f              //如果为真,那么说明还字段存在包是继承而来的子字段,不只是指定表的值。
null_frac              | 0              //该字段为空记录数的百分比
avg_width              | 4              //该字段每行的平均长度
n_distinct             | -1             //如果大于零,就是在字段中唯一数值的估计数目。如果小于零, 就是唯一数值的数目被行数除的负数。用负数形式是因为ANALYZE 认为独立数值的数目是随着表增长而增长; 正数的形式用于在字段看上去好像有固定的可能值数目的情况下。比如, -1 表示一个唯一字段,独立数值的个数和行数相同。
most_common_vals       |                //该字段最常用数值的列表。如果看上去没有啥数值比其它更常见,则为 null。主键一般为null。
most_common_freqs      |                //该字段最常用数值的频率,也就是说,每个出现的次数除以行数。 如果most_common_vals是 null ,则为 null。
histogram_bounds       | {1,100,200,300,400,500,600,700,800,900,1000,1100,1200,1300,1400,1500,1600,1700,1800,1900,2000,2100,2200,2300,2400,2500,2600,2700,2800,2900,3000,3100,3200,3300,3400,3500,3600,3700,3800,3900,4000,4100,4200,4300,4400,4500,4600,4700,4800,4900,5000,5100,5200,5300,5400,5500,5600,5700,5800,5900,6000,6100,6200,6300,6400,6500,6600,6700,6800,6900,7000,7100,7200,7300,7400,7500,7600,7700,7800,7900,8000,8100,8200,8300,8400,8500,8600,8700,8800,8900,9000,9100,9200,9300,9400,9500,9600,9700,9800,9900,10000}   //一个数值的列表,它把字段的数值分成几组大致相同热门的组。
correlation            | 1              //统计与字段值的物理行序和逻辑行序有关。它的范围从 -1 到 +1 。 在数值接近 -1 或者 +1 的时候,在字段上的索引扫描将被认为比它接近零的时候开销更少, 因为减少了对磁盘的随机访问。如果字段数据类型没有<操作符,那么这个字段为null
most_common_elems      |                //经常在字段值中出现的非空元素值的列表。(标量类型为空。)
most_common_elem_freqs |                //最常见元素值的频率列表,也就是,至少包含一个给定值的实例的行的分数。 每个元素频率跟着两到三个附加的值;它们是在每个元素频率之前的最小和最大值, 还有可选择的null元素的频率。(当most_common_elems 为null时,为null)
elem_count_histogram   |                //该字段中值的不同非空元素值的统计直方图,跟着不同非空元素的平均值。(标量类型为空。)

1.3.2 pg_statistic

pg_statistic is a view based on pg_stats, which displays statistical information in a more friendly and readable way, which can be accessed by ordinary users.

db1=# select * from pg_statistic limit 1;
-[ RECORD 1 ]----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
starelid    | 16698
staattnum   | 1
stainherit  | t
stanullfrac | 0
stawidth    | 4
stadistinct | -1
stakind1    | 2
stakind2    | 3
stakind3    | 0
stakind4    | 0
stakind5    | 0
staop1      | 97
staop2      | 97
staop3      | 0
staop4      | 0
staop5      | 0
stacoll1    | 0
stacoll2    | 0
stacoll3    | 0
stacoll4    | 0
stacoll5    | 0
stanumbers1 |
stanumbers2 | {1}
stanumbers3 |
stanumbers4 |
stanumbers5 |
stavalues1  | {1,100,200,300,400,500,600,700,800,900,1000,1100,1200,1300,1400,1500,1600,1700,1800,1900,2000,2100,2200,2300,2400,2500,2600,2700,2800,2900,3000,3100,3200,3300,3400,3500,3600,3700,3800,3900,4000,4100,4200,4300,4400,4500,4600,4700,4800,4900,5000,5100,5200,5300,5400,5500,5600,5700,5800,5900,6000,6100,6200,6300,6400,6500,6600,6700,6800,6900,7000,7100,7200,7300,7400,7500,7600,7700,7800,7900,8000,8100,8200,8300,8400,8500,8600,8700,8800,8900,9000,9100,9200,9300,9400,9500,9600,9700,9800,9900,10000}
stavalues2  |
stavalues3  |
stavalues4  |
stavalues5  |

1. Statistics related parameters

  • track_counts: Control whether to collect statistics on access to tables and indexes, the default is ON
  • track_functions: Controls whether to collect statistics on the number of function calls and execution time. The default is "none". "none" means no collection, "pl" means only collecting process language function statistics, "all" means collecting all function statistics, including SQL and C languages
  • track_activities: Control whether to collect statistics about the SQL execution of the session, the default is ON, this part of information can be viewed in pg_stat_activity
  • track_activity_query_size: Control the length limit of the query field in the pg_stat_activity view, the default is 1KB, SQL will be truncated if the size exceeds this parameter
  • track_io_timing: Control whether to collect statistics about IO calls, the default is OFF. If this parameter is enabled, explain and use the buffers option, the specific IO call time can be displayed, and the collected IO related information can be viewed in pg_stat_database, pg_stat_statements
  • update_process_title: Control whether to update the title information when the background process is executing a command, it is ON by default under Linux
  • stats_temp_directory: Set the path to store temporary statistics data, the default is pg_stat_tmp

1.4 Statistics update

1.4.1 Automatic update of statistics

1. Automatic update mechanism of statistical information

  • The autovacuum process periodically triggers automatic updates. When the autovacuum parameter is turned on (enabled by default), the autovacuum lancher process is set according to the autovacuum_naptime parameter as the frequency at which the statistical information process is awakened (default 1min), and the autovacuum_max_workers parameter is set as the number of worker threads to start each time the statistics are updated (the default is 3 )
  • The autovacuum process triggers the update when the number of rows in the table field additions, deletions, and changes reaches a certain limit. The judging rule is: When the number of rows added, deleted and modified on the table >= autovacuum_vacuum_scale_factor * reltuples (the number of records on the table) + autovacuum_vacuum_threshold.
  • Each time the statistical information is collected, only a certain proportion of the statistical data will be collected. The parameter default_statistics_target is used as the sample size. This method can easily cause the collected data to be unable to accurately estimate the accurate data of the current field when the amount of data in the table is large. Distribution information needs to be adjusted according to the actual situation
  • For table fields, you can set statistics to specify the proportion of the field's statistical information collection data rows to the number of table rows to enhance the accuracy of statistical information collection for large data scales. The statistics information is viewed in the pg_attribute table, and the settings can be changed through alter.

2. Related parameters and changes

-- autovacuum进程自动触发统计信息的更新
db1=# show autovacuum;
-[ RECORD 1 ]--
autovacuum | on

db1=# show autovacuum_naptime;
-[ RECORD 1 ]------+-----
autovacuum_naptime | 1min

db1=# show autovacuum_max_workers;
-[ RECORD 1 ]----------+--
autovacuum_max_workers | 3

-- autovacuum进程根据表变更行数触发统计信息的更新
db1=# show autovacuum_vacuum_threshold;
-[ RECORD 1 ]---------------+---
autovacuum_vacuum_threshold | 50

db1=# show autovacuum_vacuum_scale_factor;
-[ RECORD 1 ]------------------+----
autovacuum_vacuum_scale_factor | 0.2

-- 按照表容量进行抽样采集控制参数
db1=# show default_statistics_target;
-[ RECORD 1 ]-------------+----
default_statistics_target | 100

-- 按照表数据量一定比例对表字段进行抽样采集控制参数调整
db1=# select * from pg_attribute where attrelid=(select oid from pg_class where relname='t1') and attname='id2';
-[ RECORD 1 ]-+------
attrelid      | 17087
attname       | id2
atttypid      | 23
attstattarget | -1
attlen        | 4
attnum        | 2
attndims      | 0
attcacheoff   | -1
atttypmod     | -1
attbyval      | t
attstorage    | p
attalign      | i
attnotnull    | f
atthasdef     | f
atthasmissing | f
attidentity   |
attgenerated  |
attisdropped  | f
attislocal    | t
attinhcount   | 0
attcollation  | 0
attacl        |
attoptions    |
attfdwoptions |
attmissingval |

db1=# alter table t1 alter column id2 set statistics 200;
ALTER TABLE
db1=# select * from pg_attribute where attrelid=(select oid from pg_class where relname='t1') and attname='id2';
-[ RECORD 1 ]-+------
attrelid      | 17087
attname       | id2
atttypid      | 23
attstattarget | 200
attlen        | 4
attnum        | 2
attndims      | 0
attcacheoff   | -1
atttypmod     | -1
attbyval      | t
attstorage    | p
attalign      | i
attnotnull    | f
atthasdef     | f
atthasmissing | f
attidentity   |
attgenerated  |
attisdropped  | f
attislocal    | t
attinhcount   | 0
attcollation  | 0
attacl        |
attoptions    |
attfdwoptions |
attmissingval |

3、pg_stat_all_tables

This table records the last update history information of all tables. To a certain extent, you can evaluate whether the autovacuum_vacuum_scale_factor setting is reasonable based on the statistical information of the table.

db1=# delete from t1 where id>8000;
DELETE 2000
db1=# select * from pg_stat_all_tables where relid=(select oid from pg_class where relname='t1');
-[ RECORD 1 ]-------+------------------------------
relid               | 17087
schemaname          | public
relname             | t1
seq_scan            | 71
seq_tup_read        | 622500
idx_scan            | 150
idx_tup_fetch       | 2140
n_tup_ins           | 10000
n_tup_upd           | 40
n_tup_del           | 2001
n_tup_hot_upd       | 35
n_live_tup          | 7999
n_dead_tup          | 2034
n_mod_since_analyze | 2000                              //上次更新变更2000行记录
last_vacuum         |
last_autovacuum     |
last_analyze        | 2020-10-25 23:26:54.623004+08
last_autoanalyze    | 2020-10-12 14:21:44.597134+08
vacuum_count        | 0
autovacuum_count    | 0
analyze_count       | 1
autoanalyze_count   | 1

1.4.2 Manually collect statistics

1. Grammar:

analyze verbose tablename (col1,col2,...);    //verbose表示打印处理进度,可直接重新采集某一张表统计信息,也可以采集某张表的某个字段的统计信息

2. Example:

db1=# analyze verbose t1;
INFO:  analyzing "public.t1"
INFO:  "t1": scanned 52 of 52 pages, containing 7999 live rows and 2034 dead rows; 7999 rows in sample, 7999 estimated total rows
ANALYZE

db1=# select * from pg_stat_all_tables where relid=(select oid from pg_class where relname='t1');
-[ RECORD 1 ]-------+------------------------------
relid               | 17087
schemaname          | public
relname             | t1
seq_scan            | 71
seq_tup_read        | 622500
idx_scan            | 150
idx_tup_fetch       | 2140
n_tup_ins           | 10000
n_tup_upd           | 40
n_tup_del           | 2001
n_tup_hot_upd       | 35
n_live_tup          | 7999
n_dead_tup          | 0
n_mod_since_analyze | 0
last_vacuum         |
last_autovacuum     | 2020-10-25 23:28:24.553443+08
last_analyze        | 2020-10-25 23:27:46.143074+08         //上一次手动更新时间
last_autoanalyze    | 2020-10-12 14:21:44.597134+08
vacuum_count        | 0
autovacuum_count    | 1
analyze_count       | 2
autoanalyze_count   | 1
文章参考:
Postgresql统计信息概述 : https://www.cnblogs.com/wy123/p/13347176.html
PostgreSQL统计信息 : https://developer.aliyun.com/article/697692

Guess you like

Origin blog.csdn.net/weixin_37692493/article/details/109281142