PostgreSQL 的临时表、全局临时表和 Unlogged 表

概述从一个技术立场来说，在PostgreSQL中的临时表有三个不同特性，区别于普通表:  1. 临时表存储在特殊的模式（ schema）中, 以便它们只对后台创建（creating backend）可见  2. 临时表有本地缓冲区管理器管理，而非由共享缓冲区管理器管理  3.  临时表没有预写式日志  尝试思考如果按照上面的顺序，一个接着一个去掉特性会什么样子？这对于我们理解这些特性是很有意义的。首先

从一个技术立场来说，在Postgresql中的临时表有三个不同特性，区别于普通表: @H_403_8@ @H_403_8@ 1. 临时表存储在特殊的模式（ schema）中,以便它们只对后台创建（creating backend）可见 @H_403_8@ 2. 临时表有本地缓冲区管理器管理，而非由共享缓冲区管理器管理 @H_403_8@ 3. 临时表没有预写式日志 @H_403_8@ @H_403_8@ 尝试思考如果按照上面的顺序，一个接着一个去掉特性会什么样子？这对于我们理解这些特性是很有意义的。首先，其他的特性不变，只去掉第一个特性，这么做非常不好，因为一个有本地缓冲区管理器管理的表是不可以被多个 后台 （backend）同时访问，不过我们通过让每个后台（backend）访问一个单独的文件集来变相地实现。这得需要一个 全局临时表-那是一个对于所有人都可见的表，但是每个 后台（ backend）只看到自己拥有的内容。（这儿有些争论关于这个表名是否合理，或者什么表名对于这个概念更合适，但是这儿我只称为全局临时表）

同时移去前两个特性也不无道理。那么我们需要 无日志表（unlogged table）-那是一个基本的不预写式日志的普通表。（再一次，名字存在争议）对于崩溃，这样的表是不安全的：一个意外的的系统崩溃可能使得表无法挽回得损坏掉。唯一的变通方法是在每次系统重启时将表截断 @H_403_8@ @H_403_8@ 为什么会有人需要这些新的表类型？如果用户他需要一个相对固定结构的临时表，而且不希望每个新会话都要重建临时表，那么选择全局临时表是非常明智的。此外对于管理也是很方便的，使用全局临时表将避免反复创建和转移临时表的系统目录的开销，这对于某些用户来说，可能会提高效率。

无日志表为那些需要在后台（backend）共享的数据准备的，但是，我们需要承担服务器重启数据丢失的后果。举例来说，设想一个网络应用维护着一张表，表中存有当前活动的用户会话。如果服务器重启了，我们得明白这些数据得丢失。每个人都要重新登录，但是考虑到服务器很少崩溃重启，这个并不是个大问题。因为备份复制依赖于预写式日志，所以无日志表不会复制到后备服务器上。但是，这也是有好处的，跳过预写式日志会带来显著的性能提高。

我将着手在 Postgresql 9.1 中实现这些表的类型。在每种情况下，最难的部分似乎都是确保每次崩溃或重启后，做好恰当的清理工作。

总结

以上是内存溢出为你收集整理的PostgreSQL 的临时表、全局临时表和 Unlogged 表全部内容，希望文章能够帮你解决PostgreSQL 的临时表、全局临时表和 Unlogged 表所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。