并发访问控制
与事务型数据库系统通过锁机制来控制并发访问的机制不同，GPDB(与Postgresql
一样)使用多版本控制(Multiversion Concurrency Control/MVCC)保证数据一致性。这
意味着在查询数据库时，每个事务看到的只是数据的快照，其确保当前的事务不会
看到其他事务在相同记录上的修改。据此为数据库的每个事务提供事务隔离。
MVCC以避免给数据库事务显式锁定的方式，最大化减少锁争用以确保多用户环境
下的性能。在并发控制方面，使用MVCC而不是使用锁机制的最大优势是，MVCC对
查询(读)的锁与写的锁不存在冲突，并且读与写之间从不互相阻塞。
一样)使用多版本控制(Multiversion Concurrency Control/MVCC)保证数据一致性。这
意味着在查询数据库时，每个事务看到的只是数据的快照，其确保当前的事务不会
看到其他事务在相同记录上的修改。据此为数据库的每个事务提供事务隔离。
MVCC以避免给数据库事务显式锁定的方式，最大化减少锁争用以确保多用户环境
下的性能。在并发控制方面，使用MVCC而不是使用锁机制的最大优势是，MVCC对
查询(读)的锁与写的锁不存在冲突，并且读与写之间从不互相阻塞。
空间回收
libo=# vacuum test;
VACUUM
VACUUM
查询分析：
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=#
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可能会比提示的值或多或少一些
原文链接：https://www.f2er.com/postgresql/195844.html