博客转载自： http://www.cnblogs.com/daduxiong/archive/2010/08/23/1806706.html
postgresql为“大字段“的物理存储提供了TOAST功能，通过合适的配置策略能够减少IO次数和扫描块数，进而提升查询速度。
TOAST：The Oversized-Attribute Storage Technique
特点：
PostgreSQL采用固定页面大小(通常是8Kb,不象oracle在运行期间有多种选择),元组不能跨越多个页面，无法实现“大字段值“的直接存储。TOAST提供了解决方法,允许大的字段值被压缩或分裂为多个物理行。
postgresql只为部分数据类型支提供TOAST支持，为支持TOAST，数据类型必须是变长（varlena）的类型。前32位存储着以字节记的数值总长度(包括长度本身)。
TOAST采用最高的两个二进制位用于标识压缩与行外存储，因此“大字段“的逻辑长度被限制在了1GB2^(32－2)-1）。
两个位都是零，表示数值未经过TOAST方式的数值；
第32位为1，表示该数值被压缩，使用前必须先解压缩；
第31位为1，表示该数值采用行外存储，此时只是存储着一个指针，该指针指向其他的地方。另外30个位表示数据的实际尺寸，而不是解压缩或者从线外数据抓过来之后的逻辑尺寸。
行外数据被分裂成（如果压缩过，以压缩后为参考）最多TOAST_MAX_CHUNK_SIZE（这个数值略小于BLCKSZ/4，或者缺省 2K字节）字节的块，每个块都作为独立的行在TOAST表里为所属表存储。每个TOAST表都有字段chunk_id，chunk_seq和chunk_data。在chunk_id和chunk_seq上有一个唯一索引，提供对数值的快速检索。
只有表中存储超过BLCKSZ/4字节（通常是2Kb）的行才会触发，对字段进行压缩和行外存储，直到小于BLCKSZ/4字节，或者无法得到更好的结果的时候才停止。UPDATE操作过程中，未改变的字段的数值通常原样保存；因此UPDATE行外存储的记录时，如果行外数据值没有变化，将不会带来TOAST开销存在。
TOAST代码识别四种不同的存储可TOAST字段的策略：
- PLAIN避免压缩或者行外存储。只对那些非TOAST数据类型才有效。
- EXTENDED允许压缩和行外存储。大多数TOAST数据类型的缺省值。首先进行压缩，如果行仍然太大，则进行行外存储。
- EXTERNAL允许行外存储，不许压缩。使用 EXTERNAL将令那些在 text 和 bytea 字段上的子字串操作更快（代价是增加了存储空间），因此这些操作是经过优化的：如果行外数据没有压缩，那么它们只抓取需要的部分。
- MAIN允许压缩，不允许行外存储。当数据值压缩过后仍然太大将会采用行外存储。每个可以 TOAST 的数据类型都为该数据类型的字段声明一个缺省策略，但是特定表的字段的存储策略可以用ALTER TABLE SET STORAGE修改。
优点：
相对直接的存储方式来说，数据经过TOAST方式后，单个或者连续数据块中能够存储更多的数据值，对于访问非“大字段”时，能够大量减少扫描块数或者物理IO次数；
对于极少访问的含“大字段”记录，经过手动修改存储属性，采用TOAST方式，即便值小于2K的情况下同样能够带来很好的效果。
针对系统数据访问特定，灵活的采用TOAST存储策略总能够为系统带来性能的提升。
题外话：oracle的大字段的存储采用了行外的方式，对大字段默认进行段存储，同时系统默认创建索引。将大字段根据磁盘配置进行单独存储，也是提升oracle部署性能的常见方式。
