PostgreSQL temp table 全链路 实现原理

背景

表(table/relation) 作为 PostgreSQL 数据库中最为常用的一种数据库对象，用户使用极多。

因为PG 本身是事务型处理的数据库，其实现事务语义采用的两种方式：锁 和 MVCC，前者辅助实现后者 已经 其他的事务特性，而后者则用于实现事务的隔离性。

所以，用户对一个普通表的读写链路会有较多的常规锁保护，而且中间过程还需要访问非常多的共享内存变量，也会需要 轻量锁的保护。但是用户有的时候就想在当前session临时创建一个表用作数据计算，而且用户能够保证这个表是不会被其他的session访问的，这个时候如果还是走普通用户表的读写/更新逻辑，那对一些有性能需求的用户来说当前表操作链路就没有必要有那么多锁的参与了。

所以，PG 很贴心得为用户实现了 temp-table 特性，来满足用户在session 内的高性能操作一个表的临时需求。

使用

接下来简单看看 temp-table 应该如何使用。

首先temp-table 生命周期默认是 backend级别，即一个backend内部创建了temp-table之后，backend退出的时候会对当前backend 所创建的所有的temp-table进行清理。

使用很简单，按照temp-table的声明周期，有两种使用方式：

1. Backend粒度

该粒度下如果不指定drop temp table的话默认 drop的时机是在 backend 退出的时候。

postgres=# create  temp table tmp(c1 int);
CREATE TABLE
postgres=# select oid,relname,relnamespace from pg_class where relname='tmp';
  oid  | relname | relnamespace
-------+---------+--------------
 24622 | tmp     |        24585
postgres=# select oid,datname from pg_database ;
  oid  |  datname
-------+-----------
     5 | postgres
 24604 | aaa
     1 | template1
     4 | template0

此时会在名字是 postgres 数据库对应的oid目录下创建一个 tmp 表的 oid对应的数据文件t3_24622，会带有t + backendId字段，和普通的以oid命名的表区分开来。

-rw-------  1 staff  staff       0  3 13 18:31 t3_24622

我们可以操作这个 tmp表像操作普通的用户表一样，做增删改查以及索引添加。

postgres=# create index on tmp (c1 );
CREATE INDEX
postgres=# insert into tmp values (generate_series(1,10000));
INSERT 0 10000

此时对应的数据库数据文件目录下也会有对应tmp 表的索引表以及 fsm文件。

-rw-------  1 staff  staff  368640  3 13 21:30 t3_24622
-rw-------  1 staff  staff  245760  3 13 21:30 t3_24625
-rw-------  1 staff  staff   24576  3 13 21:30 t3_24622_fsm

如果我们退出backend 或者 手动drop table tmp;或者 有backend切换操作(\c other-database)，此时与 该temp-table相关的所有数据文件都会被清理。

2. Transaction粒度

该粒度下 可以指定一个事务提交时 对 temp table 的操作，transaction粒度需要在用户可控事务生命周期的事务块里 :begin, commit等；

• create temp table aaa (c1 int) on commit drop; 指定 temp table aaa 在发生commit 时（比如insert into aaa 操作）触发drop tmp table的行为
• create temp table aaa (c1 int) on commit DELETE ROWS; 会在提交时 删除事务内对当前temp table 的更新行，temp table本身的drop会在backend 退出时。
• create temp table aaa (c1 int) on commit preserve rows 会在提交时保留对 temp table 事务内的更新。

postgres=# begin;
BEGIN
postgres=*# create temp table aaa (c1 int) on commit preserve rows ;
CREATE TABLE
postgres=*#  insert into aaa values (1),(2);
INSERT 0 2
postgres=*# commit;
COMMIT
postgres=# select * from aaa;
 c1
----
  1
  2
(2 rows)

实现

接下来进入到比较有趣的数据库内核环节，关于temp table的实现链路 基本是和普通表的实现接近，包括创建、删除、插入等。

总的来说，差异点主要如下：

1. temp-table 的数据页 是由local buffer管理，而不是shared buffer，所以仅对创建它的backend可见。
2. temp-table 不会写WAL

读写链路通过如下流程图来展示就非常清晰：

从整体架构流程中能够很明显得看到temp-table 和 普通的用户表之间的异同。
从上到下可以看到 temp-table 以及 用户表读写链路上的各个组件：

• syscache & relcache， PG 为每一个session对应的backend进程单独维护了其进程本地的系统表缓存 和 表关系缓存，用于加速各个backend 内部对catalog 以及 表关系的访问。当然，这一些cache之间会通过 invalid-message 进行通信，保障不同backend之间的cache 一致性。这一部分 不论是 普通的backend 还是 创建了temp-table的backend 都有同样的访问逻辑。 差异点是对 temp-table的更新并不会发送 invalid-message 到其他的backend，不需要做cache 一致性的同步，因为 temp-table 仅会在当前backend 访问。这个过程，也不需要有锁参与。

• buffer manager，buffer-manager 组件也可以理解为是 buffer-pool ，主要用作管理 PG heap表存储引擎需要的page。buffer-manager 能够提供高效的 page访问 以及 dirty-page 淘汰策略，而page 内部则是存放 表的 tuple 行数据。关于 tuple 部分的详细描述可以参考：PostgreSQL heap表引擎实现原理。 buffer-manager 内部主要有几个小组件用于高效管理pages：

  1. HATB，其主要拥有几个组件：HASHHDR，用来保存当前hash表的控制信息，比如hash slot(segment)的个数，每一个segment的大小，freelist 指针，已经存储了多少元素等；HASHSEGMENT 一个保存元素链表的数组，数组对cpu的局部性更为友好，每一个数组元素是一个链表，保存实际存储在其中的page信息; HASHELEMENT 则是保存每一个page的hash-value，对于每一个page 都会经过 HTAB得 hashfunction 映射到某一个具体的 HASHSEGMENT 中的链表尾部。查找的时候根据 page 的 hash-value 找到 当前page属于哪一个 HASHSEGMENT，再顺序遍历其内部的链表进行hash-value 的匹配。找到对应的 HASHELEMENT之后 提取其 index。
  2. Buf Descriptor，这里通过 LocalBufferDescriptors 保存每一个page 在内存中的具体起始地址。因为page的大小是固定的，找到了起始地址，意味着就能拿到改page内部的数据。
  3. 通过 BufferDescriptor拿到的起始地址去 buffer pool中解析对应的 page 数据。

  写入链路也是需要先从hash表 --> BufferDescriptor --> page 拿到一个可以存放当前tuple的 page，然后将tuple 数据填充到当前page中并对page header的头部做一些可见性相关的修改（具体细节参见前面提到的heap 表引擎的实现原理）。

  需要注意的是， 对于temp-table的更新 ，其所在的backend 会为其创建local-buffer进行 temp-table的 page 管理，local-buffer-manger 因为没有并发访问的问题，所以其不论是访问hash表 还是更新 page，都不需要加锁。
  而对于 ordinary-table 的更新，则是通过 shared-buffer-manager。多个backend 可能会访问同一个数据表，当然shared-buffer-manager 中的数据结构和 local-buffer-manager 基本一样，差异点事对其内部的基本数据结构的访问需要加锁。

• BgWorker ，这是一批后台进程的总称。比如像是 checkpointer, walwriter 以及 background writer 都是属于 bgworker。这里主要是指 background writer，其主要负责将 dirty-page 写入到 os-page-cache中。
  走os的写链路也是以page 为粒度进行写入，buffer-manager 有一套自己的 dirty-page 逐出算法，对于 dirty-page 会通过background writer bg worker 写入到os 的 page-cache中。最终的持久化到磁盘则是通过 checkpointer进程 搭配 fsync 来完成。
  在一部分需要注意的是 普通表 在写入 shared-buffer-manager 之前，会多一个 WAL的写入。 wal 也是拥有自己的 wal-buffer 来管理 wal-record 的page，其会通过 walwriter 写入到 + fsync写入到磁盘文件。

• autovacuum，这个后台进程主要用于清理 PG 通过 MVCC 实现并发控制引入的表膨胀数据。
  在temp-table的清理中，其也会去清理某一个 backend异常退出时没有来得及清理的 无主 的 temp-table。

整个实现链路，如果关注每一个组件的代码细节，会非常复杂。接下来的原理描述也只能是概览一些代码链路，当然主要是关注 temp-table相关的链路。

创建表

创建 temp table 走的也是 基本的DDL 链路，CREATE TEMP TABLE。前面介绍 temp-table 的时候有一个细节没有提到，就是 namespace 概念。PG为了方便对整个数据库内部的表进行管理，设计了namespace，将系统表、用户表、临时表等不同schema 的表划分到不同的namespace中，对于这一些表的owner 以及 它们的权限控制就都可以转移对该表所属的 namespace的权限控制了。

比如对于一个新创建的数据库，其拥有如下几个namespace:

boydb=# select * from pg_namespace ;
  oid  |      nspname       | nspowner |                            nspacl
-------+--------------------+----------+---------------------------------------------------------------
    99 | pg_toast           |       10 |
    11 | pg_catalog         |       10 | {
    
    zhanghuigui=UC/zhanghuigui,=U/zhanghuigui}
  2200 | public             |     6171 | {
    
    pg_database_owner=UC/pg_database_owner,=U/pg_database_owner}
 12665 | information_schema |       10 | {
    
    zhanghuigui=UC/zhanghuigui,=U/zhanghuigui}
(4 rows)

可以看到默认是拥有 pg_toast, pg_catalog,informantion_shcema 以及 public 这四个namespace，其中 前三个的 nspowner 一样，都是10，这个值是从 pg_authid 中提取出来的。

boydb=# select * from pg_authid where oid=10;
 oid |   rolname   | rolsuper | rolinherit | rolcreaterole | rolcreatedb | rolcanlogin | rolreplication | rolbypassrls | rolconnlimit | rolpassword | rolvaliduntil
-----+-------------+----------+------------+---------------+-------------+-------------+----------------+--------------+--------------+-------------+---------------
  10 | zhanghuigui | t        | t          | t             | t           | t           | t              | t            |           -1 |             |

因为这个数据库是我创建的，所以 nspowner 对应的oid 就是标识是我所创建的表，我拥有对它的操作权限的体现是通过 pg_namespace的 nspacl列。

对于 oid=6171来说，它的owner 是pg_database_owner，这个角色是 PG14 版本新发布的一个特性，能够更为便捷得对用户权限进行控制。

在 temp-table场景中，如果我们创建一个 temp-table，PG 会在当前数据库中创建两个不会被删除的 pg_namespace tuple：pg_temp_3 以及 pg_toast_temp_3。其中的数字 3 表示的是 backendId，之所以也会创建 pg_toast_temp_3，是因为 toast 属性（大宽表）的存储是默认开启的，比如当前tuple的大小超过 page 1/2，会默认开启toast的存储，将实际的 tuple数据部分存储到 toast表中，原本的heap表的tupe data部分则保存指向 toast表的指针；所以temp-table的使用也需要默认有一个 temp-toast-table 的管理方式。

一个新的backend 创建临时表的主要逻辑有两部分：

1. 创建namespace: 检查当前所在的backend 进程是否有 有效的 myTempNamespace， 默认 myTempNamespace = InvalidOid 即 0；有效，则直接返回；无效，则重新创建两个新的 namespace，分别命名为 pg_temp_<MyBackendId> , pg_toast_temp_<MyBackendId>。
2. 创建实际的 temp 用户表，走正常的建表逻辑。

步骤一 初始化 namespace 的调用链路如下：

PostmasterMain
  ServerLoop
    BackendStartup
      BackendRun
        PostgresMain
          exec_simple_query
            PortalRun
              PortalRunMulti
                PortalRunUtility
                  standard_ProcessUtility
                    ProcessUtilitySlow
										transformCreateStmt // 建表语句是 `create temp table xxx();`，走 `T_CreateStmt` nodeTag
											RangeVarGetAndCheckCreationNamespace
												RangeVarGetCreationNamespace
													AccessTempTableNamespace
														InitTempTableNamespace

AccessTempTableNamespace 逻辑如下：

static void
AccessTempTableNamespace(bool force)
{
    
    
	/*
	 * Make note that this temporary namespace has been accessed in this
	 * transaction.
	 */
	MyXactFlags |= XACT_FLAGS_ACCESSEDTEMPNAMESPACE;

  /*是否是有效的 namespace */
	if (!force && OidIsValid(myTempNamespace))
		return;

	/* 无效，则创建namespace */
	InitTempTableNamespace();
}

这里需要注意 PG 创建好的 temp-namespace 的生命周期是伴随数据库的，而不是像 temp-table一样 backend 退出就会被删除。之所以这样有两方面的考虑：

1. 同一个backend 内部创建多个temp-table，namespace肯定用一个比较合适。
2. backendId 是有限的，受 MaxBackends 最大连接数的影响，所以其会被复用。所以通过创建有限个数的temp-namespace 能够防止因为重复创建namespace造成的创建 temp-table的性能损失。

创建temp-namespace 过程需要访问 pg_namespace, 如果发现能从 pg_namespace 所属的syscache 中 找到一个pg_tmpe_backendId 名字的oid，则需要先删除，再创建一个新的tuple 填充到 pg_namespace中。

确认 namespace 存在 或者 新创建完成之后，进入到创建 temp table 的过程。

步骤二 创建temp table的逻辑如下，整体是非常复杂的，需要读写的其他catalog 表较多（pg_type, pg_proc, pg_class等等）

需要注意的是每一个relation 会创建一个属于它的 smgr( storage manager)，需要用它来管理本地的数据表文件，比如需要创建/修改/删除/fsync，都是通过smgr来完成的。

PostmasterMain
  ServerLoop
    BackendStartup
      BackendRun
        PostgresMain
          exec_simple_query
            PortalRun
              PortalRunMulti
                PortalRunUtility
                  standard_ProcessUtility
                    ProcessUtilitySlow // 在 transformCreateStmt 完成namespace的创建，再调用  DefineRelation创建用户表
                      DefineRelation //创建 relation
  											heap_create_with_catalog // 创建当前relation相关的catalog

完成temp-table创建之后就是向里面插入数据。

插入

插入逻辑到还是会进入 heap 表的 heap_insert 的逻辑：

1. 通过 heap_prepare_insert 填充 tup 的 HeapTupleHeader 部分
2. 从buffer-manager 中获取一个可用的buffer index。判断是从localbuffer 中分配还是从 shared-buffer中分配，是通过前面建表时创建的 (smgr)->smgr_rnode，如果是temp表，则 满足 (smgr)->smgr_rnode.backend != InvalidBackendId。 localbuffermanager 为了和 shared-buffer 做区分，将buffer_id 初始化为了 以-1 开始，向负值方向逐渐递减递减，后续通过 LocalBufferDescriptor转为 可以获取到 LocalBufferBlockPointers buffer-pool 的page 起始地址。
3. 拿着 获取到的buffer，去LocalBufferBlockPointers 提取page的地址。其内部会通过 buffer的正负来区分是从local-buffer-pool 还是从 shared-buffer-pool 中拿page，将准备好的 tuple 数据填充到page中。
4. 处理这个 page 的可见性，并标识这个page 为dirty。
5. 通过 RelationNeedsWAL 判断是否需要写WAL，对于temp-table来说 是不需要的，因为其属性 不是 RELPERSISTENCE_PERMANENT 'p'，只有普通的用户表才会有 RELPERSISTENCE_PERMANENT 标识。
   当然整个链路大家能看到函数 UnlockReleaseBuffer 或者 LockBuffer ，这里 temp-table 链路下 对buffer 的访问 是不需要实际加锁的，其内部判读是temp-table会直接返回。
6. 发送invalid-message，更新temp-table 本地的cache

void
heap_insert(Relation relation, HeapTuple tup, CommandId cid,
			int options, BulkInsertState bistate)
{
    
    
	TransactionId xid = GetCurrentTransactionId();
	HeapTuple	heaptup;
	Buffer		buffer;
	Buffer		vmbuffer = InvalidBuffer;
	bool		all_visible_cleared = false;
  
  /* 填充 tup的 HeapTupleHeader部分 */
  heaptup = heap_prepare_insert(relation, tup, xid, cid, options);
	...
  /* 从 local buffer manager 中获取/分配 一个可用的page index */
	buffer = RelationGetBufferForTuple(relation, heaptup->t_len,
									   InvalidBuffer, options, bistate,
									   &vmbuffer, NULL);
  ...
  /* 拿着page index 找到对应的page ，将 tup的 data 信息填充到当前page中 */
  RelationPutHeapTuple(relation, buffer, heaptup,
                         (options & HEAP_INSERT_SPECULATIVE) != 0);
 
 ...
 MarkBufferDirty(buffer);
 /* XLOG stuff */
 if (RelationNeedsWAL(relation))
 {
    
    
   ...
 }
  
 	UnlockReleaseBuffer(buffer);
	if (vmbuffer != InvalidBuffer)
		ReleaseBuffer(vmbuffer);
  ...
  /* 发送invalid message，更新sys/rel cache */
  CacheInvalidateHeapTuple(relation, heaptup, NULL);
  ...
}

插入完成之后的dirty-page 会由 background writer 将脏页通过 smgrwrite 写入到os-page cache中。

删除表

对于 temp-table的删除，在不同的场景下有三种方式，它们拥有不同的调用链路，底层的执行实际删除操作的链路是一样的。

1. 创建temp-table时会去清理已经存在的 temp-namespace，此时会将这个tempnamespace 下所有的temp-relation全部删除；后续为这个backend重新创建新的temp-namespace
2. 正常的 backend 退出 会清理 temp-table的数据。
3. create temp table aaa(c1 int) on commit drop; 事务commit 时会删除 temp-table
4. DROP 命令和 DISCARD命令。 drop table aaa; , discard temp aaa;
5. backend 被kill 或者 异常退出，会由 autovacuum 完成temp-table 的清理

以上链路到最后完成数据清理时 除了 drop 和 create temp table aaa() on commit drop;是通过 RemoveRelations --> performMultipleDeletions 清理临时表之外，其他都是通过函数 performDeletion 进行的，普通表的删除是不会进入到这个逻辑。

1. DISCARD命令

其执行栈如下：

PostmasterMain
  ServerLoop
  	BackendStartup
  		BackendRun
  			PostgresMain
  				exec_simple_query
  					PortalRun
  						PortalRunMulti
  							PortalRunUtility
  								standard_ProcessUtility
  									DiscardCommand
  										ResetTempTableNamespace
  											RemoveTempRelations
  												performDeletion

2. DROP 命令

和前面 DISCARD 的命令执行调度逻辑一样，只是进入了 dropstmt 中。

...
  standard_ProcessUtility
  	ProcessUtilitySlow
  		ExecDropStmt
  			RemoveRelations
  				performMultipleDeletions

3. CREATE TEMP TABLE aa() ON COMMIT DROP;

create 这个ddl 执行完之后会直接调度 清理 temp table的清理操作。

PostmasterMain
  ServerLoop
  	BackendStartup
  		BackendRun
  			PostgresMain
  				exec_simple_query
  					finish_xact_command // create temp table aa() on commit drop; 事务执行完 commit
  						CommitTransactionCommand
  							CommitTransaction	 
  								PreCommit_on_commit_actions 
  									performMultipleDeletions // 直接调度清理

4. Backend 进程退出时

这里的调度逻辑是正常的temptable 被清理的是逻辑。

其中 RemoveTempRelationsCallback 是在完成 temp-table 创建时 会通过 before_shmem_exit 注册一个进去，这个注册在进程正常/FATAL/ERROR 退出时都能在如下调用栈中执行，保障temp-table 被调度到清理。

PostmasterMain
  ServerLoop
  	BackendStartup
  		BackendRun
  			PostgresMain
  				proc_exit
  					proc_exit_prepare
  						shmem_exit
  							RemoveTempRelationsCallback
  									RemoveTempRelations
  										performDeletion  

5. TEMP-TABLE 在新启动的backend中创建时

会在创建的过程中，在前面创建临时表时提到的 InitTempTableNamespace函数中如果找到对应backend的 pg_temp_<backendID> 的 namespaceoid，则需要先删除旧的 temp-namespace 中的所有relation。

...
  standard_ProcessUtility
  	ProcessUtilitySlow
  		transformCreateStmt
  			RangeVarGetAndCheckCreationNamespace
  				RangeVarGetCreationNamespace
  					AccessTempTableNamespace
  						InitTempTableNamespace
  							RemoveTempRelations
  								performDeletion

6. AUTOVACUUM 清理 temp-table

因为AUTOVACUUM 主要关注的是无主的temp-table，即创建该temp-table的 backend 已经被kill，却没有来得及执行 performDeletion。

do_autovacuum
  checkTempNamespaceStatus
  performDeletion

在 autovacuum 中，通过 checkTempNamespaceStatus 函数确认这个temp-table 是否是无主的，如果是无主的则将该temp-table 的 oid 添加到 orphan_oids 链表中，后续会循环 通过 performDeletion 进行清理。

关于判断一个 temp-table是否是无主的， checkTempNamespaceStatus 逻辑如下：

1. 通过GetTempNamespaceBackendId 根据 temp-table 所处的 temp-namespace-id 拿到temp-namespace的名字，解析出temp-namespace 所处的 backendId。

2. 通过 BackendIdGetProc 从 shmInvalBuffer->procState 拿到一个proc指针。如果为NULL，说明这个 proc已经挂了，直接返回 idle

   其中 shmInvalBuffer 是Shared cache invalidation memory segment，保存了整个 PG 进程组最新的 backend 列表，对其的访问和更新都是在 LWLOCK的保护下完成的。所以这里拿到的 backend 对应的 proc 指针一定是最新的。

3. 如果 backend还活着，可能是新启动的一个backend，需要进行更多的判读确保这个 temp-table 有效：

   1. 活着的 proc 访问的数据库 id 和 当前 autovacuum 的数据库ID 不匹配，说明这个PROC 不是创建temp-table 的proc，返回idle即可。

   2. 再此检查活着的 proc 访问的namespaceId 和 当前temp-table 所属的name-spaceid 是否匹配，不是则返回idle。

   3. 最后返回 IN_USE，这才是 temp-table 所属的有效的PROC，这个temp-table 的 oid 才不会被添加到 orphan_oids

TempNamespaceStatus
checkTempNamespaceStatus(Oid namespaceId)
{
    
    
	PGPROC	   *proc;
	int			backendId;

	Assert(OidIsValid(MyDatabaseId));

	backendId = GetTempNamespaceBackendId(namespaceId);

	/* No such namespace, or its name shows it's not temp? */
	if (backendId == InvalidBackendId)
		return TEMP_NAMESPACE_NOT_TEMP;

	/* Is the backend alive? */
	proc = BackendIdGetProc(backendId);
	if (proc == NULL)
		return TEMP_NAMESPACE_IDLE;

	/* Is the backend connected to the same database we are looking at? */
	if (proc->databaseId != MyDatabaseId)
		return TEMP_NAMESPACE_IDLE;

	/* Does the backend own the temporary namespace? */
	if (proc->tempNamespaceId != namespaceId)
		return TEMP_NAMESPACE_IDLE;

	/* Yup, so namespace is busy */
	return TEMP_NAMESPACE_IN_USE;
}

介绍完了几种删除链路，接下来看看 performDeletion 具体如何删除掉临时文件的？ 本质上还是通过 smgr去清理文件，需要分别清理catalog的数据和用户表的数据。

performDeletion 会先提取出要删除的relation 依赖的所有相关relation 的地址，通过 deleteOneObject --> doDeletion 挨个清理，最后会在清理物理信息：

void
heap_drop_with_catalog(Oid relid)
{
    
    
  ...
	if (RELKIND_HAS_STORAGE(rel->rd_rel->relkind))
		RelationDropStorage(rel);
  ...
}

RelationDropStorage 这个函数会将 Relation的物理文件句柄信息 rd_node 添加到 全局的 pendingDeletes 链表中。

对于 pendingDeletes 的清理时通过：CommitTransaction / AbortTransaction 时调用 smgrDoPendingDeletes集中将当前事务内部所有的 pendingDeletes 的 文件rd_node 通过 smgrdounlinkall 掉。

到此就对整个temp-table 的 创建、写入、删除链路了解的差不多了，正常运行的场景中 还是 local-buffer的管理，通过local-buffer-manager 保证 对 temp-table 链路访问的高效；当然不写 WAL （不保证temp-table的可靠性）也是高性能必要的一部分。

更重要的是通过 temp-table的切入，能够对整个数据表 在 PG 内部执行器之下的访问 更为熟悉，也能够有效的得了解到PG 在存储层的组件实现。