简单的说,这个命令就是垃圾整理,另外一个是vacuumdb
具体中文说明
http://www.kuqin.com/postgreSQL8.1_doc/sql-vacuum.html
VACUUM -- 垃圾收集以及可选地分析一个数据库
Synopsis
VACUUM [ FULL | FREEZE ] [ VERBOSE ] [ table ] VACUUM [ FULL | FREEZE ] [ VERBOSE ] ANALYZE [ table [ (column [, ...] ) ] ]
描述
VACUUM 回收已删除元组占据的存储空间。 在一般的 PostgreSQL 操作里, 那些已经 DELETE 的元组或者被 UPDATE 过后过时的元组是没有从它们所属的表中物理删除的; 在完成VACUUM 之前它们仍然存在。 因此我们有必须周期地运行 VACUUM, 特别是在常更新的表上。
如果没有参数,VACUUM 处理当前数据库里每个表, 如果有参数,VACUUM 只处理那个表。
VACUUM ANALYZE 先执行一个 VACUUM 然后是给每个选定的表执行一个 ANALYZE。 对于日常维护脚本而言,这是一个很方便的组合。参阅 ANALYZE 获取更多有关其处理的细节。
简单的 VACUUM (没有FULL) 只是简单地回收空间并且令其可以再次使用。这种形式的命令可以和对表的普通读写并行操作, 因为没有请求排他锁。VACUUM FULL 执行更广泛的处理,包括跨块移动元组,以便把表压缩到最少的磁盘块数目里。 这种形式要慢许多并且在处理的时候需要在表上施加一个排它锁。
FREEZE 是一种特殊用途的选项,它导致元组尽可能快地标记为"冻结(frozen)", 而不是等到它们已经相当老的时候才标记。如果在同一个数据库上没有其它运行着的事务的时候完成这个命令, 那么系统就保证在数据库里的所有元组都是"冻结(frozen)"的, 因此不会有事务 ID 重叠的问题,而和数据库未清理的时间没有关系。 我们不建议把 FREEZE 用做日常用途。我们用它的唯一目的是准备和用户定义的模板数据库联接的时候, 或者是其它完全是只读的, 不会等到日常维护性 VACUUM 操作的数据库。 参阅 Chapter 22 获取细节。
参数
FULL
选择"完全"清理,这样可以恢复更多的空间, 但是花的时间更多并且在表上施加了排它锁。
FREEZE
选择激进的元组"冻结"。
VERBOSE
为每个表打印一份详细的清理工作报告。
ANALYZE
更新用于优化器的统计信息,以决定执行查询的最有效方法。
table
要清理的表的名称(可以有模式修饰)。缺省时是当前数据库中的所有表。
column
要分析的具体的列/字段名称。缺省是所有列/字段。
输出
如果声明了 VERBOSE,VACUUM 发出过程信息, 以表明当前正在处理那个表。各种有关这些表的统计也会打印出来。
注意
我们建议在经常VACUUMM(清理)(至少每晚一次)生产数据库, 以保证不断地删除失效的行。尤其是在增删了大量记录之后, 对受影响的表执行 VACUUM ANALYZE 命令是一个很好的习惯。这样做将更新系统目录为最近的更改,并且允许 PostgreSQL 查询优化器在规划用户查询时有更好的选择。
我们不建议日常使用 FULL 选项,但是可以在特殊情况下使用。 一个例子就是在你删除了一个表的大部分行之后,希望从物理上缩小该表以减少磁盘空间占用。VACUUM FULL 通常要比单纯的 VACUUM 收缩更多表的尺寸。
例子
下面是一个在 regression (蜕变)数据库里某个表上执行 VACUUM的一个例子:
regression=# VACUUM VERBOSE ANALYZE onek; INFO: vacuuming "public.onek" INFO: index "onek_unique1" now contains 1000 tuples in 14 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.08u sec elapsed 0.18 sec. INFO: index "onek_unique2" now contains 1000 tuples in 16 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.07u sec elapsed 0.23 sec. INFO: index "onek_hundred" now contains 1000 tuples in 13 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.08u sec elapsed 0.17 sec. INFO: index "onek_stringu1" now contains 1000 tuples in 48 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.09u sec elapsed 0.59 sec. INFO: "onek": removed 3000 tuples in 108 pages DETAIL: CPU 0.01s/0.06u sec elapsed 0.07 sec. INFO: "onek": found 3000 removable, 1000 nonremovable tuples in 143 pages DETAIL: 0 dead tuples cannot be removed yet. There were 0 unused item pointers. 0 pages are entirely empty. CPU 0.07s/0.39u sec elapsed 1.56 sec. INFO: analyzing "public.onek" INFO: "onek": 36 pages, 1000 rows sampled, 1000 estimated total rows VACUUM
兼容性
SQL92里没有 VACUUM 语句。
这是手动的
http://postgresql-chinese.blogspot.com/2007/03/postgresql-vacuum.html
既然它都推荐自动,那就只有看自动了
默认自动整理是关闭的
编辑postgresql.conf
#------------------------------------------------------------------------------
# AUTOVACUUM PARAMETERS
#------------------------------------------------------------------------------
#autovacuum = on # Enable autovacuum subprocess? 'on'
# requires track_counts to also be on.
#log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and
# their durations, > 0 logs only
# actions running at least this number
# of milliseconds.
#autovacuum_max_workers = 3 # max number of autovacuum subprocesses
#autovacuum_naptime = 1min # time between autovacuum runs
#autovacuum_vacuum_threshold = 50 # min number of row updates before
# vacuum
#autovacuum_analyze_threshold = 50 # min number of row updates before
# analyze
#autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum
#autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze
#autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum
# (change requires restart)
#autovacuum_vacuum_cost_delay = 20ms # default vacuum cost delay for
# autovacuum, in milliseconds;
# -1 means use vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
# autovacuum, -1 means use
# vacuum_cost_limi
但是,在这个的上面,还有一个设置,改善vacuum的时机吧,从最后一个URL的测试结果来看,合适的设置应该会好很多
没太看懂
# - Cost-Based Vacuum Delay -
#vacuum_cost_delay = 0ms # 0-100 milliseconds
#vacuum_cost_page_hit = 1 # 0-10000 credits
#vacuum_cost_page_miss = 10 # 0-10000 credits
#vacuum_cost_page_dirty = 20 # 0-10000 credits
#vacuum_cost_limit = 200 # 1-10000 credits
http://www.postgresql.org/docs/current/static/runtime-config-resource.html
写道During the execution of VACUUM and ANALYZE commands, the system maintains an internal counter that keeps track of the estimated cost of the various I/O operations that are performed. When the accumulated cost reaches a limit (specified by vacuum_cost_limit), the process performing the operation will sleep for a while (specified byvacuum_cost_delay). Then it will reset the counter and continue execution.
The intent of this feature is to allow administrators to reduce the I/O impact of these commands on concurrent database activity. There are many situations in which it is not very important that maintenance commands like VACUUM and ANALYZE finish quickly; however, it is usually very important that these commands do not significantly interfere with the ability of the system to perform other database operations. Cost-based vacuum delay provides a way for administrators to achieve this.
This feature is disabled by default for manually issued VACUUM commands. To enable it, set the vacuum_cost_delay variable to a nonzero value.
vacuum_cost_delay (integer)
The length of time, in milliseconds, that the process will sleep when the cost limit has been exceeded. The default value is zero, which disables the cost-based vacuum delay feature. Positive values enable cost-based vacuuming. Note that on many systems, the effective resolution of sleep delays is 10 milliseconds; settingvacuum_cost_delay to a value that is not a multiple of 10 might have the same results as setting it to the next higher multiple of 10.
When using cost-based vacuuming, appropriate values for vacuum_cost_delay are usually quite small, perhaps 10 or 20 milliseconds. Adjusting vacuum's resource consumption is best done by changing the other vacuum cost parameters.
vacuum_cost_page_hit (integer)
The estimated cost for vacuuming a buffer found in the shared buffer cache. It represents the cost to lock the buffer pool, lookup the shared hash table and scan the content of the page. The default value is one.
vacuum_cost_page_miss (integer)
The estimated cost for vacuuming a buffer that has to be read from disk. This represents the effort to lock the buffer pool, lookup the shared hash table, read the desired block in from the disk and scan its content. The default value is 10.
vacuum_cost_page_dirty (integer)
The estimated cost charged when vacuum modifies a block that was previously clean. It represents the extra I/O required to flush the dirty block out to disk again. The default value is 20.
vacuum_cost_limit (integer)
The accumulated cost that will cause the vacuuming process to sleep. The default value is 200.
Note: There are certain operations that hold critical locks and should therefore complete as quickly as possible. Cost-based vacuum delays do not occur during such operations. Therefore it is possible that the cost accumulates far higher than the specified limit. To avoid uselessly long delays in such cases, the actual delay is calculated as vacuum_cost_delay * accumulated_balance / vacuum_cost_limit with a maximum of vacuum_cost_delay * 4.
以下貌似是测试结果
发表评论
-
自己的mysql 入门
2010-06-24 14:47 963参考 http://xyfxh.spaces.live.com ... -
postgresql DBA常用命令
2009-11-30 11:57 1225cheat sheet 1 http://www.al ... -
postgresql overlay
2009-11-25 11:12 1033http://www.postgresql.org/docs/ ... -
postgresql的pl pgsql 支持
2009-11-18 15:58 1686增加pl/pgsql的支持 标准的pos ... -
postgresql limit offset
2009-11-11 15:49 4413LIMIT 和 OFFSET 附加上 LIM ... -
postgresql备份的sh
2009-09-29 16:25 1044#!/bin/sh # Get FileName ... -
centos编译安装postgresql 8.4
2009-09-11 16:22 3971postgres发布了8.4.1 因为一直在用8.1和8.3 ... -
简单的日期判断
2008-12-22 11:22 1032判断一个日期regist_date,超过30天(一个月) o ...
相关推荐
在标题“postgresql_9.4整理下载”中,我们关注的是PostgreSQL的第9.4版本。这个版本在2015年发布,是PostgreSQL发展史上的一个重要里程碑,它引入了许多增强和新特性。 在描述中提到,PostgreSQL在Linux环境下表现...
PostgreSQL中文学习手册 PostgreSQL PostgreSQL PostgreSQL学习手册 学习手册 学习手册 (数据表 数据表 ) 4 一、表的定义: 一、表的定义: 一、表的定义: . 4 PostgreSQL PostgreSQL PostgreSQL学习手册 学习手册...
4. **自动 Vacuum 优化**:自动 Vacuum 过程进行了改进,能更好地处理大量删除和更新操作,减少存储空间的浪费。 5. **逻辑复制**:新引入的逻辑复制功能允许数据通过订阅和发布机制在不同数据库之间进行实时同步,...
8.1版本引入了一些重要的改进,比如并行VACUUM、支持XML数据类型和改进的索引系统。 总的来说,PostgreSQL作为一个开源数据库系统,不仅提供了全面的功能,也具备高度的可扩展性和适应性。无论是用于开发项目还是...
2024-01-18-【数据库】 PostgreSQL中的VACUUM作用
PostgreSQL(postgresql-14.1.tar.bz2) PostgreSQL是一种特性非常齐全的自由软件的对象-关系型数据库管理系统(ORDBMS),是以加州大学计算机系开发的POSTGRES,4.2版本为基础的对象关系型数据库管理系统。...
PostgreSQL(postgresql-14.1.tar.gz) PostgreSQL是一种特性非常齐全的自由软件的对象-关系型数据库管理系统(ORDBMS),是以加州大学计算机系开发的POSTGRES,4.2版本为基础的对象关系型数据库管理系统。POSTGRES...
A Tour of PostgreSQL Internals.pdf Inside the PostgreSQL Query Optimizer.pdf Inside the PostgreSQL Shared Buffer Cache.pdf Internals Of PostgreSQL Wal.pdf PostgreSQL Internals Through Pictures.pdf ...
PostgreSQL(postgresql-13.5.tar.bz2) PostgreSQL是一种特性非常齐全的自由软件的对象-关系型数据库管理系统(ORDBMS),是以加州大学计算机系开发的POSTGRES,4.2版本为基础的对象关系型数据库管理系统。...
PostgreSQL(postgresql-13.5.tar.gz) PostgreSQL是一种特性非常齐全的自由软件的对象-关系型数据库管理系统(ORDBMS),是以加州大学计算机系开发的POSTGRES,4.2版本为基础的对象关系型数据库管理系统。POSTGRES...
Navicat for PostgreSQL是一套专为PostgreSQL设计的强大数据库管理及开发工具。它可以用于任何版本 7.5 或以上的 PostgreSQL 数据库服务器,并支持大部份 PostgreSQL最新版本的功能,包括触发器、函数、管理用户等。...
1. **并行VACUUM**: 在此版本之前,VACUUM操作是单线程执行的,而8.3引入了并行VACUUM,允许数据库在多个CPU核心上同时进行清理工作,显著提高了维护效率,减少了长时间运行的VACUUM对业务的影响。 2. **改进的索引...
1、postgresql 1.1、安装集群 1.1.1、单机版本 1.1.2、主从复制 1.2、表分区 2、timescaledb 2.1、安装插件 2.2、单节点超表 2.3、分布式超表
- 优化了`VACUUM`和`ANALYZE`操作,提高了数据库维护效率。 3. **Windows-x64版的考虑** - 针对64位系统的优化,使得能够利用更多的系统内存,处理大数据集更为高效。 - 安装程序`PostgreSQL-9.2.4-1-windows-x...
PostgreSQL数据库内核分析PostgreSQL数据库内核分析PostgreSQL数据库内核分析PostgreSQL数据库内核分析PostgreSQL数据库内核分析PostgreSQL数据库内核分析PostgreSQL数据库内核分析PostgreSQL数据库内核分析...
PostgreSQL 14.1 手册 PostgreSQL 全球开发组 翻译:彭煜玮1,PostgreSQL中文社区2文档翻译组
### PostGreSQL在Centos 7.9上的安装与部署 #### 一、引言 在开始学习任何数据库之前,最重要的第一步就是安装部署一个可供学习和测试的环境。选择一个在业界广泛使用的操作系统版本,以及一个成熟稳定的数据库...
postgresql-42.5.0.jar是Java上的一个驱动程序,用于连接PostgreSQL数据库并与其进行交互。它可以让Java程序员方便地使用PostgreSQL数据库,并提供了许多功能和工具,使程序员可以编写高效、稳定和高性能的应用程序...
PostgreSQL是一种功能强大的开源关系型数据库管理系统,以其稳定性和可靠性而受到全球开发者的广泛赞誉。在标题和描述中提到的“postgresql 12、15离线安装包”指的是为这两个版本提供的安装程序,适用于没有互联网...