并发访问控制与事务型数据库系统通过锁机制来控制并发访问的机制不同，GPDB(与PostgreSQL 一样)使用多版本控制(Multiversion Concurrency Control/MVCC)保证数据一致性。这 意味着在查询数据库时，每个事务看到的只是数据的快照，其确保当前的事务不会 看到其
并发访问控制
与事务型数据库系统通过锁机制来控制并发访问的机制不同，GPDB(与PostgreSQL
一样)使用多版本控制(Multiversion Concurrency Control/MVCC)保证数据一致性。这
意味着在查询数据库时，每个事务看到的只是数据的快照，其确保当前的事务不会
看到其他事务在相同记录上的修改。据此为数据库的每个事务提供事务隔离。
MVCC以避免给数据库事务显式锁定的方式，最大化减少锁争用以确保多用户环境
下的性能。在并发控制方面，使用MVCC而不是使用锁机制的最大优势是，MVCC对
查询(读)的锁与写的锁不存在冲突，并且读与写之间从不互相阻塞。
空间回收
libo=# vacuum test;
VACUUM
VACUUM命令还会收集表级别的统计信息，如记录数、占用磁盘页面数，所以在
装载数据之后对全表执行VACUUM是有必要的，这同样适用AO表
查询分析：
libo=# explain select * from t where id=1;
QUERY PLAN
----------------------------------------------------------------------------
Gather Motion 1:1 (slice1; segments: 1) (cost=0.00..1.01 rows=1 width=8)
-> Seq Scan on t (cost=0.00..1.01 rows=1 width=8)
Filter: id = 1
(3 rows)
libo=# vacuum t;
VACUUM
libo=# explain select * from t where id=1;
QUERY PLAN
----------------------------------------------------------------------------
Gather Motion 1:1 (slice1; segments: 1) (cost=0.00..3.04 rows=3 width=8)
-> Seq Scan on t (cost=0.00..3.04 rows=1 width=8)
Filter: id = 1
(3 rows)
libo=#
查询计划分析
若一个查询表现出很差的性能，查看查询计划可能有助于找到问题点。下面是
一些需要查看的东西：
计划中是否有一个操作花费时间超长？查询计划中是否有一个操作花费
了大部分的处理时间？例如，如果一个索引扫描比预期的时间超长，也许
该索引已经处于过期状态，需要考虑重建索引。还可临时尝试使用enable_
之类的参数查看是否可以强制选择不同的计划(可能会更好的效果)，这些
参数可以设置特定的查询计划操作为开启或关闭状态。
规划器的评估是否接近实际情况？执行EXPLAIN ANALYZE查看规划器
评估的记录数与真实运行查询操作返回的记录数是否一致。如果差异巨大，
可能需要在TABLE相关的COLUMN上收集更多的统计信息。相关信息可
查看”维护数据库统计信息”章节。
选择性强的条件是否较早出现？选择性强的条件应该被较早应用，从而使
得在计划树中上传的记录更少。如果查询计划在选择性评估方面没有对查
询条件作出正确的判断，可能需要在TABLE相关的COLUMN上收集更多
的统计信息。相关信息可查看”维护数据库统计信息”章节。也可以尝试调
整SQL语句WHERE子句的顺序。
规划器是否选择了最佳的关联顺序？如查询使用多表关联，需要确保规划
器选择了选择性最好的关联顺序。那些可以消除大量记录的关联应在更早
的被执行，从而使得在计划树中上传的记录更少。如果规划器没有选择最
佳的关联顺序，可以尝试设置join_collapse_limit=1并在SQL语句中构造特
定的关联顺序，从而可以强制规划器选择指定的关联顺序。还可以尝试在
TABLE相关的COLUMN上收集更多的统计信息。相关信息可查看”维护数据
据库统计信息”章节。
规划器是否选择性的扫描分区表？如果使用了分区，规划器是否值扫描了
查询条件匹配的相关子表？父表的扫描返回0条记录(本该如此，因为父表
不包含任何数据)。作为显示选择性扫描分区查询计划的例子，参见”验证
分区策略”章节。
规划器是否合适的选择了HASH聚合与HASH关联操作？HASH操作通常
比其他类型的关联和聚合要快。记录在内存中的比较排序比磁盘快。要使
用HASH操作，必须有足够的工作内存用以放置评估的记录。对于特定才
查询可以尝试增加工作内存来查看是否能够获得更好的性能。如果可能，
为该查询执行EXPLAIN ANALYZE，将可以得到哪些操作缓存到磁盘(由
于工作内存不足导致)，多少的工作内存被使用，以及需要多少内存以保证
不缓存到磁盘。例如：
Work_mem used: 23430K bytes avg, 23430K bytes max (seg0).
Work_mem wanted: 33649K bytes avg, 33649K bytes max (seg0) to lessen
workfile I/O affecting 2 workers.
需要注意的是wanted信息只是一个提示，基于写出工作文件的量是不精确的。
需要的最小work_mem可能会比提示的值或多或少一些
