PostgreSQL 英文原文：Global Temporary and Unlogged Tables 从一个技术立场来说，在PostgreSQL中的临时表有三个不同特性，区别于普通表:

1. 临时表存储在特殊的模式（ schema）中, 以便它们只对后台创建（creating backend）可见
2. 临时表有本地缓冲区管理器管理，而非由共享缓冲区管理器管理
3. 临时表没有预写式日志

尝试思考如果按照上面的顺序，一个接着一个去掉特性会什么样子？这对于我们理解这些特性是很有意义的。首先，其他的特性不变，只去掉第一个特性，这么做非常不好，因为一个有本地缓冲区管理器管理的表是不可以被多个 后台  （backend）同时访问，不过我们通过让每个后台（backend）访问一个单独的文件集来变相地实现。这得需要一个 全局临时表 -那是一个对于所有人都可见的表，但是每个 后台（ backend）只看到自己拥有的内容。（这儿有些争论关于这个表名是否合理，或者什么表名对于这个概念更合适，但是这儿我只称为全局临时表） 同时移去前两个特性也不无道理。那么我们需要 无日志表（unlogged table） -那是一个基本的不预写式日志的普通表。（再一次，名字存在争议）对于崩溃，这样的表是不安全的：一个意外的的系统崩溃可能使得表无法挽回得损坏掉。唯一的变通方法是在每次系统重启时将表截断 

为什么会有人需要这些新的表类型？如果用户他需要一个相对固定结构的临时表，而且不希望每个新会话都要重建临时表，那么选择全局临时表是非常明智的。此外对于管理也是很方便的，使用全局临时表将避免反复创建和转移临时表的系统目录的开销，这对于某些用户来说，可能会提高效率。

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

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

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务