greenplum收集统计信息
Name
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。对于⽇常维护
脚本⽽⾔，这是⼀个很⽅便的组合。参阅获取更多有关其处理的细节。
简单的 VACUUM （没有FULL）只是简单地回收空间并且令其可以再次使⽤。这种形式的命令可以和对表的普通读写并⾏操作，因为没有请求排他锁。VACUUM FULL 执⾏更⼴泛的处理，包括跨块移动元组，以便把表压缩到最少的磁盘块数⽬⾥。这种形式要慢许多并且在处理的时候需要在表上施加⼀个排它锁。
FREEZE 是⼀种特殊⽤途的选项，它导致元组尽可能快地标记为"冻结(frozen)"，⽽不是等到它们已经相当⽼的时候才标记。如果在同⼀个数据库上没有其它运⾏着的事务的时候完成这个命令，那么系统就保证在数据库⾥的所有元组都是"冻结(frozen)"的，因此不会有事务 ID 重叠的问题，⽽和数据库未清理的时间没有关系。我们不建议把 FREEZE ⽤做⽇常⽤途。我们⽤它的唯⼀⽬的是准备和⽤户定义的模板数据库联接的时候，或者是其它完全是只读的，不会等到⽇常维护性 VACUUM 操作的数据库。参阅获取细节。
参数
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 "k"
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 "k"
INFO:  "onek": 36 pages, 1000 rows sampled, 1000 estimated total rows
VACUUM
定期使⽤Vacuum analyze tablename 回收垃圾和收集统计信息，尤其在⼤数据量删除，导⼊以后，⾮常重要
vacuum分两种，⼀种是analize优化查询计划的，还有⼀种是清理垃圾数据，
vacuum分两种，⼀种是analize优化查询计划的，还有⼀种是清理垃圾数据，
vacuum，该选项主要是清理数据库表中的垃圾空间
定义：
VACUUM reclaims storage occupied by deleted tuples. In normal Greenplum Database operation, tuples that are deleted or obsoleted by an update are not physically removed from their table; they re
main present on disk until a VACUUM is done. Therefore it is necessary to do VACUUM periodically, especially on frequently-updated tables.
With no parameter, VACUUM processes every table in the current database. With a parameter, VACUUM processes only that table.
即对于delete或update操作造成的实际物理空间没有从所对应的表中移除的话，vacuum操作可以将此磁盘释放出来，所以对那些经常性更新的表很有需要来做下vacuum操作。
postres删除⼯作，并不是真正删除数据，⽽是在被删除的数据上，坐⼀个标记，只有执⾏vacuum时，才会真正的物理删除，这个⾮常重⽤，有些经常更新的表，各种查询、更新效率会越来越慢，这个多是因为没有做vacuum的原因。
查看执⾏计划：
ssg=# explain select * from "xxx".tb1 limit 100;
QUERY PLAN
----------------------------------------------------------------------------------------------
Limit  (cost=0.00..3.21 rows=100 width=547)
->  Gather Motion 2:1  (slice1; segments: 2)  (cost=0.00..3.21 rows=50 width=547)
->  Limit  (cost=0.00..1.21 rows=50 width=547)
->  Seq Scan on tb1  (cost=0.00..119124.70 rows=4923135 width=547)
(4 rows)
ssg=# EXPLAIN ANALYZE select * from "xxx".tb1 limit 100;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------
Limit  (cost=0.00..3.21 rows=100 width=547)
Rows out:  100 rows with 6.182 ms to first row, 6.227 ms to end, start offset by 1132 ms.
->  Gather Motion 2:1  (slice1; segments: 2)  (cost=0.00..3.21 rows=50 width=547)
Rows out:  100 rows at destination with 6.136 ms to first row, 6.155 ms to end, start offset by 1132 ms.
->  Limit  (cost=0.00..1.21 rows=50 width=547)
Rows out:  Avg 100.0 rows x 2 workers.  Max 100 rows (seg0) with 1.016 ms to first row, 1.044 ms to end, start offset by 1137 ms.
->  Seq Scan on tb1  (cost=0.00..119124.70 rows=4923135 width=547)
greenplum数据库Rows out:  Avg 100.0 rows x 2 workers.  Max 100 rows (seg0) with 1.006 ms to first row, 1.016 ms to end, start offset by 1137 ms.
Slice statistics:
(slice0)    Executor memory: 215K bytes.
(slice1)    Executor memory: 231K bytes avg x 2 workers, 231K bytes max (seg0).
Statement statistics:
Memory used: 128000K bytes
Total runtime: 1148.336 ms
(14 rows)
ssg=#

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。