由于PostgreSQL MVCC，an
UPDATE实际上更像是
DELETEplus
INSERT。除了烘烤值的显着例外-请参阅：
- Postgres是否在更新时重写整行？
（和仅堆元组的微小差异-
DELETE+
INSERT启动了一个新的HOT链-但这与手头的情况无关。）
准确地说，“删除”行对于提交删除之后开始的任何事务来说都是不可见的，以后再进行清理。因此，在数据库方面，包括索引操作，实际上这两个语句之间 没有区别
。（有例外，请继续阅读。）这会稍微增加网络流量（取决于您的数据），并且需要一些解析。
在@araqnid输入之后，我研究了HOT更新，并进行了一些测试。就HOT更新而言， 实际上不更改值的 列更新 没有任何区别
。我的答案成立。请参阅下面的详细信息。
这也适用于烘烤的属性，因为除非值 实际更改， 否则它们也不会被触摸。
但是 ，如果您使用 每列触发器 （第9.0页介绍），则可能会有不希望的副作用！
我引用了有关触发器的手册：
…这样的命令
UPDATE ... SET x = x ...将在列上触发触发器x， 即使该列的值未更改也是如此 。
大胆强调我的。
抽象层是为了方便。它们对于不懂SQL的开发人员或在不同RDBMS之间需要可移植的应用程序很有用。不利的一面是，它们可能会削弱性能并引入其他故障点。我会尽可能避免它们。
HOT（仅堆元组）更新
Postgres
8.3引入了仅堆元组，在8.3.4和8.4.9中进行了重要改进。
Postgres 8.3的发行说明：
UPDATEs和DELETEs留下死元组，失败的INSERTs也是如此。以前只能VACUUM回收死元组占用的空间。使用HOT死元组空间可以在INSERT或UPDATE
在未更改索引列 时自动回收 。这样可以实现更一致的性能。同样，HOT避免添加重复的索引条目。
强调我的。并且“无更改”包括使用相同的值更新列的情况。我不确定， 实际上已经测试过 。
最终，源代码中广泛的README.HOT确认了这一点。
烤列也不会妨碍HOT更新。HOT更新的元组仅链接到关系的吐司中的相同，未更改的元组。HOT更新甚至可以与目标列表中的烘烤值（实际上是否更改）一起工作。如果更改了烘烤值，则显然需要对烘烤关系叉进行写操作。我也测试了所有这些。
不要相信我，自己去看看。Postgres提供了一些检查统计信息的功能。在
UPDATE有和没有所有列的情况下运行您的应用程序，并检查是否有任何不同。
-- Number of rows HOT-updated in table:SELECT pg_stat_get_tuples_hot_updated('table_name'::regclass::oid)-- Number of rows HOT-updated in table, in the current transaction:SELECT pg_stat_get_xact_tuples_hot_updated('table_name'::regclass::oid)或使用pgAdmin。选择表并检查主窗口中的“统计”选项卡。
请注意，只有在主关系分支的同一页上有新元组版本的空间时，才可以进行HOT更新。强制该条件的一种简单方法是使用仅容纳几行的小表进行测试。页面大小通常为8k，因此页面上必须有可用空间。
