2007-04-11

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 ...

網誌存檔

PostgreSQL & Google-Analytics Running...

::Planet PostgreSQL::

PostgreSQL Information Page

PostgreSQL日記(日本 石井達夫先生Blog)

PostgreSQL News

黑喵的家 - 資料庫相關

Google 網上論壇
PostgreSQL 8 DBA 專業指南中文版
書籍內容討論與更多下載區(造訪此群組)
目錄下載: PostgreSQL_8 _DBA_Index_zh_TW.pdf (更新:2007-05-18)

全球訪客分佈圖(Google)

全球訪客分佈圖(Google)