关于postgresql节点的信息

【postgresql】数据库函数返回字符串问题

(1)"pg_catalog"."varchar" 字符串

(2)"pg_catalog"."bool" 布尔值

(3)"pg_catalog"."int" 数值

(4)"public"."table" 表

现有一个pgsql递归查询，递归查询父级节点并拼接成字符串，查询语句如下

查询结果为

将该查询语句放在函数中，运行没问题，但是使用函数查询时报错，报错如下：

类型转换问题，需要强制将返回结果转为字符串类型 varchar

将查询修改为

将上传查询放到函数中，可以正常查询。

如何提高postgresql查询性能

一、使用EXPLAIN：

PostgreSQL为每个查询都生成一个查询规划，因为选择正确的查询路径对性能的影响是极为关键的。PostgreSQL本身已经包含了一个规划器用于寻找最优规划，我们可以通过使用EXPLAIN命令来查看规划器为每个查询生成的查询规划。

PostgreSQL中生成的查询规划是由1到n个规划节点构成的规划树，其中最底层的节点为表扫描节点，用于从数据表中返回检索出的数据行。然而，不同

的扫描节点类型代表着不同的表访问模式，如：顺序扫描、索引扫描，以及位图索引扫描等。如果查询仍然需要连接、聚集、排序，或者是对原始行的其它操作，那

么就会在扫描节点"之上"有其它额外的节点。并且这些操作通常都有多种方法，因此在这些位置也有可能出现不同的节点类型。EXPLAIN将为规划树中的每

个节点都输出一行信息，显示基本的节点类型和规划器为执行这个规划节点计算出的预计开销值。第一行(最上层的节点)是对该规划的总执行开销的预计，这个数

值就是规划器试图最小化的数值。

这里有一个简单的例子，如下：

复制代码 代码如下:

EXPLAIN SELECT * FROM tenk1;

QUERY PLAN

-------------------------------------------------------------

Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244)

EXPLAIN引用的数据是：

1). 预计的启动开销(在输出扫描开始之前消耗的时间，比如在一个排序节点里做排续的时间)。

2). 预计的总开销。

3). 预计的该规划节点输出的行数。

4). 预计的该规划节点的行平均宽度(单位：字节)。

这里开销(cost)的计算单位是磁盘页面的存取数量，如1.0将表示一次顺序的磁盘页面读取。其中上层节点的开销将包括其所有子节点的开销。这里的输出

行数(rows)并不是规划节点处理/扫描的行数，通常会更少一些。一般而言，顶层的行预计数量会更接近于查询实际返回的行数。

现在我们执行下面基于系统表的查询：

复制代码 代码如下:

SELECT relpages, reltuples FROM pg_class WHERE relname = 'tenk1';

从查询结果中可以看出tenk1表占有358个磁盘页面和10000条记录，然而为了计算cost的值，我们仍然需要知道另外一个系统参数值。

复制代码 代码如下:

postgres=# show cpu_tuple_cost;

cpu_tuple_cost

----------------

0.01

(1 row)

cost = 358(磁盘页面数) + 10000(行数) * 0.01(cpu_tuple_cost系统参数值)

下面我们再来看一个带有WHERE条件的查询规划。

复制代码 代码如下:

EXPLAIN SELECT * FROM tenk1 WHERE unique1 7000;

QUERY PLAN

------------------------------------------------------------

Seq Scan on tenk1 (cost=0.00..483.00 rows=7033 width=244)

Filter: (unique1 7000)

EXPLAIN的输出显示，WHERE子句被当作一个"filter"应用，这表示该规划节点将扫描表中的每一行数据，之后再判定它们是否符合过滤的条

件，最后仅输出通过过滤条件的行数。这里由于WHERE子句的存在，预计的输出行数减少了。即便如此，扫描仍将访问所有10000行数据，因此开销并没有

真正降低，实际上它还增加了一些因数据过滤而产生的额外CPU开销。

上面的数据只是一个预计数字，即使是在每次执行ANALYZE命令之后也会随之改变，因为ANALYZE生成的统计数据是通过从该表中随机抽取的样本计算的。

如果我们将上面查询的条件设置的更为严格一些的话，将会得到不同的查询规划，如：

复制代码 代码如下:

EXPLAIN SELECT * FROM tenk1 WHERE unique1 100;

QUERY PLAN

------------------------------------------------------------------------------

Bitmap Heap Scan on tenk1 (cost=2.37..232.35 rows=106 width=244)

Recheck Cond: (unique1 100)

- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37 rows=106 width=0)

Index Cond: (unique1 100)

这里，规划器决定使用两步规划，最内层的规划节点访问一个索引，找出匹配索引条件的行的位置，然后上层规划节点再从表里读取这些行。单独地读取数据行比顺

序地读取它们的开销要高很多，但是因为并非访问该表的所有磁盘页面，因此该方法的开销仍然比一次顺序扫描的开销要少。这里使用两层规划的原因是因为上层规

划节点把通过索引检索出来的行的物理位置先进行排序，这样可以最小化单独读取磁盘页面的开销。节点名称里面提到的"位图(bitmap)"是进行排序的机

制。

现在我们还可以将WHERE的条件设置的更加严格，如：

复制代码 代码如下:

EXPLAIN SELECT * FROM tenk1 WHERE unique1 3;

QUERY PLAN

------------------------------------------------------------------------------

Index Scan using tenk1_unique1 on tenk1 (cost=0.00..10.00 rows=2 width=244)

Index Cond: (unique1 3)

在该SQL中，表的数据行是以索引的顺序来读取的，这样就会令读取它们的开销变得更大，然而事实上这里将要获取的行数却少得可怜，因此没有必要在基于行的物理位置进行排序了。

现在我们需要向WHERE子句增加另外一个条件，如：

复制代码 代码如下:

EXPLAIN SELECT * FROM tenk1 WHERE unique1 3 AND stringu1 = 'xxx';

QUERY PLAN

------------------------------------------------------------------------------

Index Scan using tenk1_unique1 on tenk1 (cost=0.00..10.01 rows=1 width=244)

Index Cond: (unique1 3)

Filter: (stringu1 = 'xxx'::name)

新增的过滤条件stringu1 = 'xxx'只是减少了预计输出的行数，但是并没有减少实际开销，因为我们仍然需要访问相同数量的数据行。而该条件并没有作为一个索引条件，而是被当成对索引结果的过滤条件来看待。

如果WHERE条件里有多个字段存在索引，那么规划器可能会使用索引的AND或OR的组合，如：

复制代码 代码如下:

EXPLAIN SELECT * FROM tenk1 WHERE unique1 100 AND unique2 9000;

QUERY PLAN

-------------------------------------------------------------------------------------

Bitmap Heap Scan on tenk1 (cost=11.27..49.11 rows=11 width=244)

Recheck Cond: ((unique1 100) AND (unique2 9000))

- BitmapAnd (cost=11.27..11.27 rows=11 width=0)

- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37 rows=106 width=0)

Index Cond: (unique1 100)

- Bitmap Index Scan on tenk1_unique2 (cost=0.00..8.65 rows=1042 width=0)

Index Cond: (unique2 9000)

这样的结果将会导致访问两个索引，与只使用一个索引，而把另外一个条件只当作过滤器相比，这个方法未必是更优。

现在让我们来看一下基于索引字段进行表连接的查询规划，如：

复制代码 代码如下:

EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 100 AND t1.unique2 = t2.unique2;

QUERY PLAN

--------------------------------------------------------------------------------------

Nested Loop (cost=2.37..553.11 rows=106 width=488)

- Bitmap Heap Scan on tenk1 t1 (cost=2.37..232.35 rows=106 width=244)

Recheck Cond: (unique1 100)

- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37 rows=106 width=0)

Index Cond: (unique1 100)

- Index Scan using tenk2_unique2 on tenk2 t2 (cost=0.00..3.01 rows=1 width=244)

Index Cond: ("outer".unique2 = t2.unique2)

从查询规划中可以看出(Nested

Loop)该查询语句使用了嵌套循环。外层的扫描是一个位图索引，因此其开销与行计数和之前查询的开销是相同的，这是因为条件unique1

100发挥了作用。 这个时候t1.unique2 =

t2.unique2条件子句还没有产生什么作用，因此它不会影响外层扫描的行计数。然而对于内层扫描而言，当前外层扫描的数据行将被插入到内层索引扫描

中，并生成类似的条件t2.unique2 = constant。所以，内层扫描将得到和EXPLAIN SELECT * FROM tenk2

WHERE unique2 = 42一样的计划和开销。最后，以外层扫描的开销为基础设置循环节点的开销，再加上每个外层行的一个迭代(这里是 106

* 3.01)，以及连接处理需要的一点点CPU时间。

如果不想使用嵌套循环的方式来规划上面的查询，那么我们可以通过执行以下系统设置，以关闭嵌套循环，如：

复制代码 代码如下:

SET enable_nestloop = off;

EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 100 AND t1.unique2 = t2.unique2;

QUERY PLAN

------------------------------------------------------------------------------------------

Hash Join (cost=232.61..741.67 rows=106 width=488)

Hash Cond: ("outer".unique2 = "inner".unique2)

- Seq Scan on tenk2 t2 (cost=0.00..458.00 rows=10000 width=244)

- Hash (cost=232.35..232.35 rows=106 width=244)

- Bitmap Heap Scan on tenk1 t1 (cost=2.37..232.35 rows=106 width=244)

Recheck Cond: (unique1 100)

- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37 rows=106 width=0)

Index Cond: (unique1 100)

这个规划仍然试图用同样的索引扫描从tenk1里面取出符合要求的100行，并把它们存储在内存中的散列(哈希)表里，然后对tenk2做一次全表顺序扫

描，并为每一条tenk2中的记录查询散列(哈希)表，寻找可能匹配t1.unique2 =

t2.unique2的行。读取tenk1和建立散列表是此散列联接的全部启动开销，因为我们在开始读取tenk2之前不可能获得任何输出行。

此外，我们还可以用EXPLAIN ANALYZE命令检查规划器预估值的准确性。这个命令将先执行该查询，然后显示每个规划节点内实际运行时间，以及单纯EXPLAIN命令显示的预计开销，如：

复制代码 代码如下:

EXPLAIN ANALYZE SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 100 AND t1.unique2 = t2.unique2;

QUERY PLAN

----------------------------------------------------------------------------------------------------------------------------------

Nested Loop (cost=2.37..553.11 rows=106 width=488) (actual time=1.392..12.700 rows=100 loops=1)

- Bitmap Heap Scan on tenk1 t1 (cost=2.37..232.35 rows=106 width=244) (actual time=0.878..2.367 rows=100 loops=1)

Recheck Cond: (unique1 100)

- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37

rows=106 width=0) (actual time=0.546..0.546 rows=100 loops=1)

Index Cond: (unique1 100)

- Index Scan using tenk2_unique2 on tenk2 t2

(cost=0.00..3.01 rows=1 width=244) (actual time=0.067..0.078 rows=1

loops=100)

Index Cond: ("outer".unique2 = t2.unique2)

Total runtime: 14.452 ms

注意"actual time"数值是以真实时间的毫秒来计算的，而"cost"预估值是以磁盘页面读取数量来计算的，所以它们很可能是不一致的。然而我们需要关注的只是两组数据的比值是否一致。

在一些查询规划里，一个子规划节点很可能会运行多次，如之前的嵌套循环规划，内层的索引扫描会为每个外层行执行一次。在这种情况下，"loops"将报告

该节点执行的总次数，而显示的实际时间和行数目则是每次执行的平均值。这么做的原因是令这些真实数值与开销预计显示的数值更具可比性。如果想获得该节点所

花费的时间总数，计算方式是用该值乘以"loops"值。

EXPLAIN ANALYZE显示的"Total runtime"包括执行器启动和关闭的时间，以及结果行处理的时间，但是它并不包括分析、重写或者规划的时间。

如果EXPLAIN命令仅能用于测试环境，而不能用于真实环境，那它就什么用都没有。比如，在一个数据较少的表上执行EXPLAIN，它不能适用于数量很

多的大表，因为规划器的开销计算不是线性的，因此它很可能对大些或者小些的表选择不同的规划。一个极端的例子是一个只占据一个磁盘页面的表，在这样的表

上，不管它有没有索引可以使用，你几乎都总是得到顺序扫描规划。规划器知道不管在任何情况下它都要进行一个磁盘页面的读取，所以再增加几个磁盘页面读取用

以查找索引是毫无意义的。

二、批量数据插入：

有以下几种方法用于优化数据的批量插入。

1. 关闭自动提交：

在批量插入数据时，如果每条数据都被自动提交，当中途出现系统故障时，不仅不能保障本次批量插入的数据一致性，而且由于有多次提交操作的发生，整个插入效

率也会受到很大的打击。解决方法是，关闭系统的自动提交，并且在插入开始之前，显示的执行begin

transaction命令，在全部插入操作完成之后再执行commit命令提交所有的插入操作。

2. 使用COPY：

使用COPY在一条命令里装载所有记录，而不是一系列的INSERT命令。COPY命令是为装载数量巨大的数据行优化过的，它不像INSERT命令那样灵

活，但是在装载大量数据时，系统开销也要少很多。因为COPY是单条命令，因此在填充表的时就没有必要关闭自动提交了。

3. 删除索引：

如果你正在装载一个新创建的表，最快的方法是创建表，用COPY批量装载，然后创建表需要的任何索引。因为在已存在数据的表上创建索引比维护逐行增加要快。当然在缺少索引期间，其它有关该表的查询操作的性能将会受到一定的影响，唯一性约束也有可能遭到破坏。

4. 删除外键约束：

和索引一样，"批量地"检查外键约束比一行行检查更加高效。因此，我们可以先删除外键约束，装载数据，然后在重建约束。

5. 增大maintenance_work_mem：

在装载大量数据时，临时增大maintenance_work_mem系统变量的值可以改进性能。这个系统参数可以提高CREATE

INDEX命令和ALTER TABLE ADD FOREIGN KEY命令的执行效率，但是它不会对COPY操作本身产生多大的影响。

6. 增大checkpoint_segments：

临时增大checkpoint_segments系统变量的值也可以提高大量数据装载的效率。这是因为在向PostgreSQL装载大量数据时，将会导致

检查点操作(由系统变量checkpoint_timeout声明)比平时更加频繁的发生。在每次检查点发生时，所有的脏数据都必须flush到磁盘上。

通过提高checkpoint_segments变量的值，可以有效的减少检查点的数目。

7. 事后运行ANALYZE：

在增加或者更新了大量数据之后，应该立即运行ANALYZE命令，这样可以保证规划器得到基于该表的最新数据统计。换句话说，如果没有统计数据或者统计数据太过陈旧，那么规划器很可能会选择一个较差的查询规划，从而导致查询效率过于低下。

postgresql 创建数据库出现以下错误，新手求解

创建数据库

选择开始菜单中→程序→【Management SQL Server 2008】→【SQL Server Management Studio】命令，打开【SQL Server Management Studio】窗口，并使用Windows或 SQL Server身份验证建立连接。

在【对象资源管理器】窗口中展开服务器，然后选择【数据库】节点

右键单击【数据库】节点，从弹出来的快捷菜单中选择【新建数据库】命令。

执行上述操作后，会弹出【新建数据库】对话框。在对话框、左侧有3个选项，分别是【常规】、【选项】和【文件组】。完成这三个选项中的设置会后，就完成了数据库的创建工作，

在【数据库名称】文本框中输入要新建数据库的名称。例如，这里以“新建的数据库”。

在【所有者】文本框中输入新建数据库的所有者，如sa。根据数据库的使用情况，选择启用或者禁用【使用全文索引】复选框。

在【数据库文件】列表中包括两行，一行是数据库文件，而另一行是日记文件。通过单击下面的【添加】、【删除】按钮添加或删除数据库文件。

切换到【选项页】、在这里可以设置数据库的排序规则、恢复模式、兼容级别和其他属性。

切换到【文件组】页，在这里可以添加或删除文件组。

完成以上操作后，单击【确定】按钮关闭【新建数据库】对话框。至此“新建的数据”数据库创建成功。新建的数据库可以再【对象资源管理器】窗口看到。

PostgreSQL学习系列—EXPLAIN ANALYZE查询计划解读

PostgreSQL命令 EXPLAIN ANALYZE 是日常工作中了解和优化SQL查询过程所用到的最强大工具，后接如 SELECT ... ， UPDATE ... 或者 DELETE ... 等SQL语句，命令执行后并不返回数据，而是输出查询计划，详细说明规划器通过何种方式来执行给定的SQL语句。

下面是从 Postgres Using EXPLAIN 提取的查询：

它生成的查询计划：

Postgres构建了一个规划节点的树结构，以表示所采取的不同操作，其中root根和每个 - 指向其中一个操作。在某些情况下， EXPLAIN ANALYZE 会提供除执行时间和行数之外的额外执行统计信息，例如上面例子中的 Sort 及 Hash 。除第一个没有 - 的行之外的任何行都是诸如此类的信息，因此查询的结构是：

每个树分支代表子动作，从里到外以确定哪个是“第一个”发生（尽管同一级别的节点顺序可能不同）。

在 tenk_unique1 索引上执行的第一个操作是 Bitmap Index Scan ：

这对应于SQL WHERE t1.unique1 100 。Postgres查找与条件 unique1 100 匹配的行位置。此处不会返回行数据本身。成本估算 (cost=0.00..5.04 rows=101 width=0) 意味着Postgres预期将“花费” 任意计算单位的 5.04 来找到这些行。0.00是此节点开始工作的成本（在这种情况下，即为查询的启动时间）。 rows 是此索引扫描将返回的预估行数， width 是这些返回行的预估大小（以字节为单位）（0是因为这里只关心位置，而不是行数据的内容）。

因为使用了 ANALYZE 选项运行 EXPLAIN ，所以查询被实际执行并捕获了计时信息。 (actual time=0.049..0.049 rows=100 loops=1) 表示索引扫描执行了1次（ loops 值），结果返回了100行，实际时间是0 ..如果节点执行了多次，实际时间是每次迭代的平均值，可以将该值乘以循环次数以获取实际时间。基于成本的最小/最大时间的概念，范围值也可能会有所不同。通过这些值，我们可以为该查询生成一个成本比率，每个成本单位为0.049ms / 5.04单位≈0.01ms/单位。

索引扫描的结果将传递给 Bitmap Heap Scan 操作。在此节点中，Postgres将获取别名为t1的tenk1表中行的位置，根据 unique1 100 条件筛选并获取行。

当乘以之前计算的0.01值时，我们可以得到成本预期的大概时间（229.20 - 5.07）*0.01≈2.24ms，同时每行实际时间为除以4后的结果：0.526ms。这可能是因为成本估算是取的上限而不是取所有需读取的行，也或者因为Recheck条件总是生效。

和表顺序读取行（a Seq Scan ）相比， Bitmap Index Scan 和 Bitmap Heap Scan 关联操作成本要昂贵得多，但是因为在这种情况下只需要访问相对较少的行，所以关联操作最终会变得更快。通过在获取行之前将行按照物理顺序排序来进一步加速，这会将单独获取的成本降到最低。节点名称中的“Bitmap”完成了排序操作。

表扫描的结果（tenk1表中满足 unique1 100 条件的那些行）将在读取时被插入到内存的哈希表中。正如我们从成本中看到的那样，这根本不需要时间。

哈希节点包括散列桶(hash buckets)和批次数(batches)相关的信息，以及内存使用峰值情况。如果批次 1，则还会包括未显示的磁盘使用信息。内存占用在100行* 244字节= 24.4 kB时是有意义的，它非常接近28kB，我们假定这是哈希键本身所占用的内存。

接下来，Postgres从别名为t2的tenk2表读取所有的10000行，并根据tenk1表行的Hash检查它们。散列连接意味着将一个表的行输入到内存中的散列（先前的操作中已构建），之后扫描另一个表的行，并根据散列表探测其值以进行匹配。在第二行可以看到“匹配”的条件， Hash Cond: (t2.unique2 = t1.unique2) 。请注意，因为查询是从tenk1和tenk2中选择所有值，所以在散列连接期间每行的宽度加倍。

现在已经收集了满足条件的所有行，可以对结果集进行排序 Sort Key: t1.fivethous 。

Sort节点包含排序算法 quicksort 相关的信息 ，排序是在内存中还是在磁盘上完成（这将极大地影响速度），以及排序所需的内存/磁盘空间量。

熟悉如何解读查询计划会非常有助于优化查询。例如，Seq Scan节点通常表示添加索引的必要性，读取速度可能要快得多。

翻译并编辑，原文出处：

如何在Kubernetes中部署一个高可用的PostgreSQL集群环境

虽然 kubernetes 社区一直在努力使得有状态应用成为一等公民，也推出了 statefulset 控制器支持 pod 的顺序部署，稳定的域名访问和存储访问。但鉴于 MySQL 部署运维的多样性和复杂性，在 kubernetes 上部署 MySQL 仍然要面临众多挑战。

1、业务流量入口的配置方式

传统虚拟机环境下，我们通过虚IP的方式，让业务应用都配置事先定义的一个虚IP为链接数据库的地址，然后由高可用服务保证虚IP始终能被路由到master数据库。在kubernetes中，出现了一层网络插件屏蔽了底层网络拓扑，高可用服务管理虚IP的方式需要随之适应调整，比如通过service结合标签完成虚IP的漂移，但service本身是kubernetes提供的一项功能，其可靠性和性能都取决于kubernetes服务的稳定。以性能来说，service是kubeproxy组件通过配置iptables实现的，当iptables规则较多时不可避免的会产生时延，需要我们针对性的解决。

2、容器隔离带来的监控视野问题

在 kubernetes 中，如果将 MySQL 制作为 container 运行在一个 pod 中，container 会将 MySQL 进程和运行环境隔离在一个单独的 namespace 中。监控组件在获取 MySQL 的一些 metirc 时，可能不得不进入与 MySQL 同一个 namespace 中，在部署和设计监控组件时需要考虑到这些限制。

3、存储在 kubernetes 中，支持配置各种不同的存储。

如果使用本地存储 local persistent volume，则需要绑定 MySQL 在一个固定的节点，这就完全浪费了 kubernetes 灵活调度的天然优势；而如果使用远程共享存储，确实是将 MySQL 进程与其存储完全解耦，使得 MySQL 进程可以在任意节点调度，然而考虑到高 I/O 吞吐量的情况，就不是那么美好了。设计时需要考量远程存储是否能够满足 MySQL 的带宽要求。

4、高可用/备份恢复

kubernetes 提供的 statefulset 控制器只能提供最基本的部署，删除功能，无法实现完善的 MySQL 集群高可用/备份恢复操作。对于有状态应用的部署，仍需要定制开发，所以多数公司提供了定制的 operator 来完成应用容器的管理。比如 etcd operator，MySQL operator，后文将为大家详述我测试使用 MySQL operator 的一些记录。

postgresql 怎么做快照

1．在服务器端选中一台客户机右击，然后点击“客户端属性”，弹出客户端属性对话框

2.在客户端对话框中，先将下端还原操作系统的“勾”去掉，然后点击“高级”出现客户端高级设置对话框，在系统盘设置中将缓存存放位置选为服务端，其他地方不要做任何更改。

3.重启该客户机，开始安装软件，安装过程中，会发现该机器缓存大小这一栏里缓存数值不断增加，直至安装完软件。（重新启动，再次运行该软件，以便确定该软件是否运行正常）

4.关闭客户机，等服务器上该客户机状态显示为未运行后，在服务端点击“镜像管理”

5.在镜像菜单中选中该客户机使用的镜像，单击“快照管理”按钮。

6.选中该客户机使用的快照节点，然后点击“生成快照”

7.在cache文件选项中选中制作快照的客户机，会自动填充下面的缓存路径，在快照信息子项中输入快照名名称和快照描述信息，点击“确定”按钮后，快照则做好了。

8选中所有客户机右击打开客户端属性对话框，在“启动菜单设置”中，将新做成的快照节点推送到用于启动的镜像这一栏中移动到最顶端，点击确定。

PostGreSQL采用“快照”方式来实现MVCC。具体地说，这意味着每一个事务中的查询仅能看到：

1.该事务启动之前已经提交的事务所作出的数据更改。

2.当前事务中该查询之前的查询所作出的更改。

PostGreSQL在每个事务启动时为该事务获取一个当前的数据库快照，快照中数据结构如下：

typedef struct SnapshotData

{

SnapshotSatisfiesFunc satisfies; /*行测试函数指针*/

TransactionId xmin; /* id小于xmin的所有事务更改在当前快照中可见 */

TransactionId xmax; /* id大于xmax的所有事务更改在当前快照中可见 */

uint32 xcnt; /* 正在运行的事务的计数 */

TransactionId *xip; /* 所有正在运行的事务的id列表 */

/* note: all ids in xip[] satisfy xmin = xip[i] xmax */

int32 subxcnt; /* # of xact ids in subxip[], -1 if overflow */

TransactionId *subxip; /* array of subxact IDs in progress */

CommandId curcid; /* in my xact, CID curcid are visible */

uint32 active_count; /* refcount on ActiveSnapshot stack */

uint32 regd_count; /* refcount on RegisteredSnapshotList */

bool copied; /* false if it’s a static snapshot */

} SnapshotData;

Transaction启动时形成快照就是要记录该Transaction可见的TransactionID，排除不可见的ID。PostGreSQL中每一个版本的数据有两个ID，其中一个是CreationID即插入该数据的TransactionID，一个是ExpiredID，即删除或更新该数据的TransactionID。对一个Transaction可见的数据的ID要满足以下条件：

1.CreationID当前TransactionID

2.ExpiredID当前TransactionID或ExpiredID不存在

Transaction启动形成快照的过程：

遍历当前所有活动的Transaction，记录在一个活动Transaction的ID数组中；根据Transaction的先后顺序，选择当前Transaction可见的最小TransactionID，记录在xmin，选择可见的最大TransactionID，记录在xmax中。

PostGreSQL8.5中进行最终的版本选择是在从外存中获取一个页面的数据之后，由一个检验函数（HeapTupleSatisfiesMVCC等一系列函数）检验所有该页面数据的数据对当前Transaction的可见性，如果不可见，则将数据除去，最后返回所有可见数据。