Postgres：缩小触发范围

Question

（Postgres 8.3）

我正在使用数据库表 X 100+列（我不能悲伤地改变），其中许多通过正常的业务流程不断更新。

我需要根据异常业务流程更新的 X 中特定列 foo 的更新来更新表 Y 。但是，由于针对 X 的更新次数非常多，只需应用检查 X.foo 的触发器来决定是否更新 Y 不可接受的。

表 Y 也不是这一行的结尾，有一些祖先链很深，所有这些都需要冒泡到根。

我能想到的唯一解决方案是：

• 将 X 分成多个表（不允许）
• 明确地将 Y （以及 Z 和其他）的更新作为更新 X 的业务逻辑的一部分，但这将是占有很大的空间，并且当他们必须在另一个过程中实现相同的功能时，会为错误或错过它的人留下很大的空间。这显然不是好设计（我正在尝试逐步修复我的设计）。

有没有人知道通过列或任何其他替代方法限制触发器执行的方法？触发视图？其他伏都教？

Answer 1

不幸的是，在版本9.0发布之前（which includes both column triggers and a WHEN clause for triggers），您将不得不采用第二种解决方案。

Answer 2

你可能能够对规则做些什么，但是之前已经说过，触发器可能应该“足够好”。但是，如果您正在尝试解决管理问题而不是技术问题，那么规则可能对您有所帮助。他们会在执行期间提前申请。小心他们通常使用序列等方面的一些陷阱。

Answer 3

为什么标准触发器不可接受？运行一个函数，它首先检查NEW.column_name=OLD.column_name是否为{{1}}，如果它是相同的则返回它是便宜的。你可以在一秒钟内发射数十万个。您的系统每秒可能无法处理超过数百个事务 - 减少3个数量级。

条件之后，9.0中的延迟触发器会更快，但只比普通触发器快2倍。请参阅a relevant post博客中的Depesz。您可以在Postgres 9 development version中运行一些基准测试。