PostgreSQL烤面包的味道好极了TOAST _toast

文章插图
在传统的数据库中，DBA最恨听到的词就是，我要使用 BLOB 字段，或者类似的类型来处理，huge的数据，他可能是一段图形的在转换后的“乱码”，也可能是某个蹩脚程序设计出来的 “怪胎” 。如果是强有力的 DBER 可能直接驳回此类需求，但换来的是，“这不有这个字段嘛”，为啥不让用，就你事多的，我就存几行诸如此类的，“欢迎词” 。
的管理员们是否会得到这样的欢迎词，就与他对的TOAST 的了解以有关。PG的默认的数据也大小是多少，8K，与SQL 类似。MYSQL 是16KB的PAGE页（默认）

文章插图
那TOAST 首先的含义以及出现的需求就有了，因为默认的数据库的页面，无法处理大容量的数据，所以针对大容量的数据就产生了一些字段的类型，来满足某些“变态” 的需求。TOAST的含义其实就是通过对大字段的分解，将其分配到多个物理行上的方式。所以一个大面包，把他切片，然后就是叫“吐司”，TOAST的名词来源可能是这样来的。
当然如果仅仅想到就是将多个物理行进行组织后来存储大型数据，未免想的还是少了一点，任何数据库的数据要进行处理，都需要走内存的这一关，而如何将大字段与内存进行一个友好的“匹配”，那就还得在费点功夫。
这里如果对PG 陌生的话，先纠正一个概念，TOAST不是一个字段类型，他是一种底层数据存储的方式，在其上方才是那些需要扩展的字段类型，所以大型字段的存储都要经过TOAST一关。
还是先感官再理论，否则按照什么理论来发散，脑子大约会开始陷入停转可能。
TABLE( text);
INTO
(
(chr(floor(() * 26)::int + 65), '')
FROM (1,10000))
FROM (1,10);
在你的PG上（我这里的版本是11），运行了上面的语句，插入一堆数据后

文章插图
我就得到了关于下面的这个图，一个存储数据的toast表的实际内容是什么样的

文章插图
下面总结一下TOAST
1 PG的大容量数据和实体表不是存在一起的
2 PG会分配一个表来单独存储分出来的数据
3 这个表里面会存储大容量的数据。

文章插图
4 在这个专门存储toast的数据类型也是有选择的，json , text,, bytea等类型都会将数据存储在这个实体表对应的toast表中。
5 TOAST 的在存储数据的时候有四种模式 plain (不使用toast)（默认压缩，既要压缩，也要行外存储） (不压缩，直接使用行外存储) Main模式（压缩，但行外存储会排在最后的选择范围）
那这里就会对上面的产生一个问题，就是我们在处理这样的数据的时候，这四种可以选择的类型，那种是最优选，或者有什么推荐，或者还是使用默认的模式。

文章插图
参看上面的文字，其中对于上面四种模式中给出了建议，使用Main 模式

文章插图
怎么修改优化，参见下面的语句

ALTERTABLE YourTableALTERCOLUMN YourColumn SET STORAGE (PLAIN | EXTENDED | EXTERNAL |MAIN)所以总结一下，PG 在处理比较大的字段上并没有什么问题，但涉及不合理的事情其实与能不能接受，倒是无关，主要是数据库种类这么多，为何非要在一个数据库上“拼死拼活”， 不如找一个更合适字段处理特别大的数据的数据库，他不香吗？

文章插图

文章插图
【PostgreSQL烤面包的味道好极了TOAST】

文章插图