PostgreSQL , pg_xlogdump , 数据库profile
在PostgreSQL中查看TOP SQL是比较方便的，如下：
《PostgreSQL 如何查找TOP SQL (例如IO消耗最高的SQL)》
而从另一个角度，比如REDO文件，我们也能分析出每个时间段数据库的操作类型，分析数据库资源消耗，以及提出优化建议。
要查看redo日志，不得不提pg_xlogdump，原理和介绍详见如下
《PostgreSQL xlog dump - pg_xlogdump 源码讲解》
我们简单的看看某个REDO文件的内容：
pg_xlogdump 000000050000159E00000095 000000050000159E00000099|less rmgr: Btree len (rec/tot): 42/ 74, tx: 891772656, lsn: 159E/95000CA0, prev 159E/94FFEC78, bkp: 0000, desc: insert: rel 1663/56867/10216768; tid 19180/150 rmgr: Btree len (rec/tot): 34/ 66, tx: 891772656, lsn: 159E/95000CF0, prev 159E/95000CA0, bkp: 0000, desc: insert: rel 1663/56867/10906168; tid 150019/337 rmgr: Transaction len (rec/tot): 12/ 44, tx: 891772656, lsn: 159E/95000D38, prev 159E/95000CF0, bkp: 0000, desc: commit: 2017-05-04 13:15:50.262106 CST rmgr: Heap2 len (rec/tot): 26/ 58, tx: 0, lsn: 159E/95000D68, prev 159E/95000D38, bkp: 0000, desc: clean: rel 1663/56867/10216762; blk 402406 remxid 891772032 rmgr: Heap len (rec/tot): 25/ 8065, tx: 891772657, lsn: 159E/95000DA8, prev 159E/95000D68, bkp: 1000, desc: lock 891772657: rel 1663/56867/10216770; tid 39310/2 LOCK_ONLY EXCL_LOCK rmgr: Heap len (rec/tot): 36/ 8116, tx: 891772657, lsn: 159E/95002D48, prev 159E/95000DA8, bkp: 0100, desc: update: rel 1663/56867/10216770; tid 39310/2 xmax 891772657 ; new tid 122748/1 xmax 0 rmgr: Btree len (rec/tot): 18/ 5238, tx: 891772657, lsn: 159E/95004D18, prev 159E/95002D48, bkp: 1000, desc: insert: rel 1663/56867/10216776; tid 15681/11 rmgr: Transaction len (rec/tot): 12/ 44, tx: 891772657, lsn: 159E/950061A8, prev 159E/95004D18, bkp: 0000, desc: commit: 2017-05-04 13:15:50.320538 CSTrmgr是指这笔REDO RECORD的类别，后面是长度等信息。
通过以下命令，可以统计每个资源有多少笔redo记录，描述是什么？
pg_xlogdump 000000050000159E00000095 000000050000159E00000099|grep -v " lock "| awk '{print $2" "$16" "$17}'|sort |uniq -c|sort -n -r 178464 Gin Insert item, 39060 Gin Vacuum page, 30980 Heap2 clean: rel 23855 Gin Vacuum data 22240 Btree insert: rel 18068 Heap insert: rel 15650 Heap2 visible: rel 8516 Heap delete: rel 4057 Transaction commit: 2017-05-04 3727 XLOG full-page image: 3331 Gin Insert new 3026 Heap update: rel 1196 Transaction abort: 2017-05-04 1191 Gin Update metapage, 765 Btree vacuum: rel 755 Heap hot_update: rel 243 Gin Delete list 55 Btree insert_upper: rel 50 Btree split_r: rel 32 Btree unlink_page: rel 32 Btree mark_page_halfdead: rel 29 Btree reuse_page: rel 28 Heap2 freeze_page: rel 27 Standby running xacts: 27 Heap insert(init): rel 20 Heap inplace: rel 11 Btree delete: index 9 Heap2 cleanup info: 5 Standby AccessExclusive locks: 5 Btree split_l: rel 4 Gin Page split, 2 XLOG checkpoint: redo 2 Gin Create posting 1 Heap update(init): rel这个日志可以看出什么问题呢？
比如我们可以看到Gin的REDO非常多，说明用户使用了GIN索引，同时这个索引的写入，更新非常频繁。
对于这种情况，用户可以设置GIN索引的fastupdate特性，同时调大vacuum naptime，以及调大表的vacuum阈值，尽量的减少GIN的合并频率，（但是fastupdate会降低检索性能）。
其他，
如果你看到VACUUM非常多，说明这些REDO中包含大量的垃圾回收信息，用户可能产生了较多垃圾，正在被回收。
如果是VACUUM FREEZE较多，说明冻结较多，用户可以修改一下冻结周期，减少这种REDO。
《PostgreSQL 使用pg_xlogdump找到误操作事务号》
《PostgreSQL xlog dump - pg_xlogdump 源码讲解》
《PostgreSQL 如何查找TOP SQL (例如IO消耗最高的SQL)》
