54.2. TOAST

本节提供一个TOAST的概述。（超大字段存储技术）

因为PostgreSQL的页面大小是固定的(通常是 8Kb)，并且不允许行跨越多个页面，因此不可能直接存储非常大的字段值。为了突破这个限制，大的字段值被压缩和/或打碎成多个物理行。这些事情对用户都是透明的，只是在后端代码上有一些小的影响。这个技术称为TOAST。（"切片面包之后最好的东西"）

只有一部分数据类型支持TOAST(没必要在那些不可能生成大的字段值的数据类型强制这种额外开销)。要支持TOAST，数据类型必须有变长 (varlena)表现形式，这个时候，任何存储的数值的头 32 位都是存储着以字节记的数值的总长度(包括长度本身)。TOAST 并不约束剩下的表现形式。所有支持TOAST 的数据类型之 C 级别的函数都必须仔细处理TOAST 的输入值。也就是通常是在对一个输入值做任何事情之前调用PG_DETOAST_DATUM；但是在某些情况下也存在更高效的方法。

TOAST 占用变长的长度字的两位（在大型机器上高位序，在小型机器上低位序），因此限制可TOAST数据类型任何值的逻辑大小为1 GB（2³⁰ - 1 字节）。当两位都是零时，该值是一个普通的非TOAST数据类型的值，长度字的剩下位给总数据大小以字节计。（包括长度字）当设置最高或最低位，该值仅有一个字节头替代通常的4字节头，而剩余的位给总数据大小以字节计。（包括长度字）作为一个特殊的情况下，如果剩余位都是零（其将不可能包含自身的长度），该值为一个指向存储在TOAST表的行外数据。（一个TOAST指针的大小是给定的在第二个字节的数据。）单字节头的值没有对齐任何特定的边界。最后当清除最高或最低位时，但是设置了临近的位，压缩了数据内容，在使用前必须解压缩。在这种情况下长度字剩余位给压缩数据的总大小，而不是原数据的。请注意压缩也可能是行外数据，但是变长的头不会告诉这是否发生—TOAST指针的内容告诉这些，替代。

如果一个表中有任何一个字段是可以TOAST的，那么该表将有一个关联的TOAST表，其 OID 存储在表的 pg_class.reltoastrelid记录里，行外TOAST过的数值保存在TOAST表里，下面有更详细的描述。

这里使用的压缩技术是非常简单并且非常快速的 LZ 族压缩技术。参阅src/backend/utils/adt/pg_lzcompress.c获取细节。

将外数据分割成(如果压缩过，在压缩之后)最多TOAST_MAX_CHUNK_SIZE (缺省选择这个值， 2000字节，使4块行将适合一内存页，约2000个字节)字节，每个块都作为独立的行在TOAST表里为所属表存储。每个TOAST表都有chunk_id 字段(一个表示特定TOAST值的 OID)、chunk_seq (一个序列号，存储该块在数值中的位置)、chunk_data(该块实际的数据)。在chunk_id和chunk_seq上有一个唯一索引，提供对数值的快速检索。因此，一个表示行外TOAST值的指针数据需要存储要查阅的TOAST的 OID 和特定数值的 OID(它的chunk_id)。为了方便，指针数据还存储逻辑数据的尺寸(原始的未压缩的数据长度)以及实际存储的尺寸 (如果使用了压缩，则两者不同)。加上头部的长度字，一个TOAST指针数据的总尺寸是 20 字节，不管它代表的数值的实际长度是多大。

TOAST代码只有在准备向某表中存储超过TOAST_TUPLE_THRESHOLD 字节(通常是 2KB)的行的时候才会触发。TOAST代码将压缩和/或行外存储字段值，直到数值比TOAST_TUPLE_TARGET字节（通常是2KB）短，或者无法得到更好的结果的时候才停止。在一个 UPDATE 操作过程中，未改变的字段值通常原样保存；所以，如果 UPDATE 一个带有行外数据的行时，如果行外数据值没有变化，那么将不会有TOAST开销存在。

TOAST代码识别四种不同的存储可TOAST字段的策略：

PLAIN避免压缩或者行外的存储;此外，它禁止使用单字节的头变长类型。这只是对那些不能 TOAST 的数据类型才有可能。
EXTENDED允许压缩和行外存储。这是大多数可以TOAST的数据类型的缺省。首先将企图进行压缩，如果行仍然太大，那么则进行行外存储。
EXTERNAL允许行外存储，但是不许压缩。使用EXTERNAL，将令那些在text和bytea字段上的子字符串操作更快 (代价是增加了存储空间)，因为这些操作是经过优化的：如果行外数据没有压缩，那么它们只会去抓取需要的部分。
MAIN允许压缩，但不允许行外存储。实际上，在这样的字段上仍然会进行行外存储，但只是作为没有办法把数据行变得更小的情况下使之足以容纳一个页面的最后的手段。

每个可TOAST的数据类型都为该数据类型的字段指定一个缺省策略，但是特定表的字段的存储策略可以用ALTER TABLE SET STORAGE修改。

这个方法比那些更直接的方法，比如允许行值直接跨越多个页面，有更多优点。假设查询通常是用相对比较短的键值进行匹配的，那么大多数执行器的工作都将使用主行记录完成。TOAST的属性的大值，只是在把结果集发送给客户端的时候才抽出来(如果选择了它的话)。因此，主表要小得多，并且它的大部分行都存储在共享缓冲区里，因此就可以不需要任何行外存储。排序集也缩小了，并且排序将更多地在内存里完成。一个小测试表明，一个用于保存 HTML 页面以及它们的 URL 的表，包括TOAST表在内，存储将近一半大小的裸数据，而主表只包含全部数据的 10%(URL 和一些小的 HTML 页面)。与在一个非TOAST的对比表里面存储(把全部 HTML 页面裁剪成 7KB 以匹配页面大小)，没有任何运行时的区别。