PostgreSQL 8.3的新功能［HOT］（二）（簡體）

更新:2007-04-11
對映章節:
【PostgreSQLウォッチ】第35回 性能を大幅に改善するPostgreSQL 8.3の新機能「HOT」とは

（原文來自日经BP网站的“PostgreSQL观察”栏目，作者是石井达夫先生。）

下边，简单地解释HOT的工作原理。
另外，正如文章开头描述的那样，PostgreSQL 8.3还在开发中，今后还会有些变化，也有不同实现的可能性。说不定，最坏比如8.3根本不会发布的情况也会出现（当然这种可能性非常低）。

抑制索引废弃领域的增加
假设有如下一个管理网页访问次数的简单数据表，当某个URL被访问时cnt增加计数，这是一个频繁更新的典型案例。
CREATE TABLE t1(
url TEXT PRIMARY KEY,-- 主键，自动附加索引
cnt INTEGER
);
cnt更新时，url字段的关联索引也会被更新。考虑一下cnt发生变更而url没有变化的情况，这时url的索引更新是没有必要的。而在HOT下，这样的索引更新不会发生，因而能够抑制索引肥大化。
这个没有关联索引更新的行为被称呼为「HEAP ONLY TUPLE」（HOT就是这样命名的）。

不使用VACUUM抑制数据表的废弃领域
更新cnt时，这行数据被删除（正确地说是在这个时刻变得不可见），然后追加新的数据行。被删除的行中放置一个被删除标志，以及一个指向新行的指针。再次更新这行数据时，从旧行的指针很容易找到新行，然后用上边提到的同样方式在这里放置指向新行的指针。这样反复更新的话就会形成一个指针链，叫做更新链（UPDATE chain）。
更新链越长检索和更新花费的时间就越长，直到运行VACUUM才会消除这种影响，这是现在PostgreSQL的问题点。
HOT也会形成更新链，这一点没有变化，但是如果没有其他的事务参照，对于HEAP ONLY TUPLE而言，会不调用VACUUM而仅仅回收删除行。能这样做的原因就是不需要从索引参照HEAP ONLY TUPLE。回收是用SELECT处理进行的，沿着HEAP ONLY TUPLE的更新链一边前进一边判断这一行是否需要废弃，如果可以废弃的话则作为可再利用对象处理。因此，它能够把更新链的长度控制在最短。
在SELECT时做这样的处理会有overhead的担心，通常PostgreSQL对数据表的访问是以块为单位进行，而上边对更新链的寻址是在已经读入块的缓存之上处理的，不会产生额外的I/O，因此几乎不会影响效率。
当然更新后的数据如果不写入数据块是不能进行这样的处理的，这个时候运行VACUUM就变得必要，实际业务中许多案例更新后的长度并没有增长很多，我认为也不会有什么大的影响。

To be continued ...