PostgreSql pageinspect 更深的理解PG

如果使用MYSQL 相对页面的层次进行一些了解，估计你就的找大佬们的工具集合，并且为此膜拜大佬们，但PG并不需要这样，PG自身自带的pageinspect 工具，就可以让你对页面级别的层次来进行一个 “透心凉” 的查看和分析，并不在为此苦恼。

首先确认您是否拥有了 pageinspect 这个 extension ，下图通过查看pg_extension这个表您可以确认，当前您的PG上已经安装了这个extension.

如果没有请 create extension pageinspect; 执行这条预计在您当前的数据块中，如果还不行，请您确认您的PG 安装与编译是否正常。

select * from heap_page_items(get_raw_page('test',0)) order by lp_off desc;

通过上面的的图，是可以推理出数据存储是从页尾开始的，数据的插入顺序与步进之间的关系。

SELECT * from page_header(get_raw_page('test', 0));

lower = 72 , 通过这里可以获知当前PG的表TEST 中曾经有过多少tumple(在这一刻)，PG的每页有28bytes 的页头，同时每个指针是4bytes ，(72 - 28)/4 = 11 ,证明当前的指针有11个。

我们插入一条记录

insert into test select generate_series(1,1), random()*100, random()*1, now();

从上图可以看出，指针并未有变化，并通过查看数据和页面的情况，看到新插入的记录，使用了之前空出的 ctid (0,1) 位置，所以指针并不需要在重新分配。

我们继续在插入两条记录，可以看出指针分配了4个字节，并且新的记录也插入了未分配的空间，每行的偏移量是64bytes

我们删除 ID > 5 的记录

然后 vacuum test表

通过命令我们也可以看到 vacuum 后的空间回收了，并且页头也重新标记了次页面的容量，但指针是不在回收了。

通过上面几个简单的命令就可以，理解一些枯燥乏味的PG 某些原理，也是不错的体验。

如果还不理解上面的意思可以看下面这个图（由于信息量太大，所以只能截断成两个图）

这两张图拼在一起，呈现的就是一个完整的页面上面28个字节头，+ 每个指针 下面就是你存储的每行数据，所以在此证明了页面存储的方式和逻辑中间的0 都是未占用的空间。

我想到此也就没有什么人不在不理解 PG的页面了，试问还有那个数据库在不通过第三方的插件或软件的情况下，能如此通透的展现一个页面在你面前。

SELECT get_raw_page::text FROM get_raw_page('test', 0);

相关的页面获得的源代码，将页面的内容memcpy到buffer 然后给大家展现出来。

那如果有人问，你的数据到底占用了多少个页面，我看看看怎么来通过某种方式来回答他。

1 一个页面我有多少数据

2 一共有多少行数据

2 /1 约等于 多少页面

我们看看上面的算法是不是可以应用到PG 中

从结果看，还是比较准确的。