基于MVCC的闪回查询功能
背景
PolarDB PG目前基于flog(flashback log)的闪回查询，需要先构建出目标时间点的表数据，然后再查询，在表较大且从闪回查询目标时间点到现在的page修改较多的场景下，闪回时间较长，基本上是分钟级别的闪回查询。而pg数据库在vacuum之前会保留一定数量的历史版本数据，因此理论上可以通过历史版本数据来实现闪回查询，提升查询性能。
原理
基于mvcc的闪回查询原理比较简单，只需要在查询的时候识别tuple的哪些历史版本是可见的即可。因此，每个tuple的xin和xmax都需要去记录一个时间戳。tagert time为闪回查询目标时间，满足以下公式的tuple查询是可见的。
time of xmin < tagert time < time of xmax
记录tagert time依赖pg原生的track commit timestamp功能。
实验
闪回查询性能
对比基于flog的闪回查询与基于mvcc的闪回查询 [1] 性能差异。测试1m数据的表，update某条tuple，并查询该tuple update之前的数据：
create table employees1 (idint primary keynotnull, salary int);
insertinto employees1 SELECT generate_series(0,1000000) askey, (random()*(10^4))::integer;
selectnow();
update employees1 set salary = 100whereid = 500000;
select * from employees1 asoftimestamp''whereid = 500000;
实验结果，基于flog闪回查询耗费7s，基于mvcc闪回查询耗费0.8ms，时间上相差8750倍。
开启track_commit_timestamp对性能影响
track commit timestamp功能据原开发作者的说法会对数据库性能造成一定影响。虽然影响较小，但是对于不依赖该模块的用户来说，不应该承担性能损失，哪怕是比较小的性能损失。
This module is disabled by default because it causes a performance hit,but can be enabled in postgresql.conf requiring only a server restart.
使用pgbench对开启和关闭track_commit_timestamp场景下的数据库性能进行压测。
pgbench -h 127.0.0.1 -p 5432 -U postgres -i -s 1000
pgbench -h 127.0.0.1 -p 5432 -U postgres -n -r -c 16 -j 16 -P 1 -M prepared -T 300
压测性能在正负3%浮动，在测量误差范围内，暂时未能得到对数据库性能影响的准确数据，需要进一步得到更精确的测量数据。但基本可以判断至少对数据库性能的影响较小。
小结
基于flog闪回查询需要先构造闪回表，再查询表的数据，构造闪回表时间随着表大小增大而增大，且由于目前仅支持seqscan，查询时间也会与表大小成正比；基于mvcc闪回查询只需要在正常查询的基础上判断xid，时间可以忽略不计，由于加了索引，表的大小对闪回查询时间影响较小。不过基于mvcc闪回查询受限于历史版本，为了避免表膨胀以及影响查询性能，一般只用于闪回查询几个小时内的数据。
总结
基于mvcc闪回查询方案对于大表的闪回查询在时间上有明显的优势，不过基于性能考虑只能用于闪回几个小时内的闪回查询。未来可结合基于flog和基于mvcc两种方式进行闪回查询，在不影响数据库原来vacuum基础上查询历史版本，如果闪回查询目标时间点在历史版本内，可以使用基于mvcc的方式进行闪回查询，提升闪回查询的性能；如果闪回查询目标时间点不在历史版本内，则仍可以用原基于flog的方式进行闪回查询。
参考
[1] https://www.postgresql.org/message-id/flat/78aadf6b-86d4-21b9-9c2a-51f1efb8a499@postgrespro.ru
