| PostgreSQL 9.4.4 中文手册 | |||
|---|---|---|---|
| 上一页 | 上一级 | 章 59. 数据库物理存储 | 下一页 |
本节对TOAST进行介绍。（超大字段存储技术）
因为PostgreSQL的页面大小是固定的(通常是8Kb)， 并且不允许元组跨越多个页面，因此不可能直接存储非常大的字段值。 为了突破这个限制，大的字段值被压缩和/或分割为多个物理行。 这些事情对用户都是透明的，只对多数后端代码有少许影响。 该技术被称之为TOAST（或者"切片面包之后最好的东西")）。
只有一部分数据类型支持TOAST —(没必要在那些不可能生成大的字段值
的数据类型强制添加这种额外开销)。要支持TOAST，数据类型必须有变长
(varlena)表现形式，这个时候，存储的任何数据的头
32 位都存储着以字节计的数据的总长度(包括长度本身)。
TOAST并不影响数据类型其余部分的表现形式。所有支持TOAST数据类型的
C级别函数都必须仔细处理TOAST的输入值。
也就是通常在对一个输入值做任何事情之前调用PG_DETOAST_DATUM；
但是在某些情况下也存在更高效的方法。
TOAST占用变长的长度字的两位（在大端（big-endian）机器上是高位序，在小端（little-endian）机器上是低位序）， 因此限制TOAST数据类型任何值的逻辑大小为1 GB（230 - 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指针数据的总大小是18字节， 不管它代表的数值的实际长度是多大。
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以匹配页面大小)进行对比，没有任何运行时的区别。