pgroll项目中添加带volatile默认值列的性能问题分析

在数据库迁移工具pgroll的使用过程中，我们发现了一个关于添加带volatile默认值列的性能问题。这个问题涉及到PostgreSQL的底层机制，对于需要执行在线数据库迁移的开发者和DBA来说尤为重要。

问题背景

在PostgreSQL 11及更高版本中，添加带有非volatile默认值的列时，数据库引擎进行了优化，不再需要全表重写操作。然而，当添加带有volatile默认值的列时，PostgreSQL仍然会执行全表重写，并在整个操作期间持有ACCESS_EXCLUSIVE锁。

问题表现

当执行包含以下操作的迁移时：

1. 创建一个包含基础列的表
2. 向表中插入大量数据（如数千万行）
3. 添加带有volatile默认值的新列（如使用random()函数）

整个操作期间，目标表会被完全锁定，导致应用程序无法访问该表，直到所有行的默认值计算和填充完成。对于大型表，这可能导致显著的停机时间。

技术原理

PostgreSQL处理列添加操作的方式取决于默认值的性质：

• 非volatile默认值：PostgreSQL 11+可以仅更新系统目录，实际值在读取时计算
• volatile默认值：必须立即计算并存储到每一行，因为每次读取可能产生不同结果

这种差异源于volatile函数的特性——它们在每次调用时可能返回不同的值，因此不能延迟计算。

解决方案

pgroll项目提出的解决方案是分阶段执行此类迁移：

1. 首先添加不带默认值的可空列
2. 使用UPDATE语句逐步填充默认值（可分批执行以减少锁争用）
3. 最后添加默认值约束

这种方法避免了长时间持有ACCESS_EXCLUSIVE锁，允许应用程序在迁移过程中继续访问表。

实现考量

在实现这种优化时需要考虑：

1. 如何区分volatile和非volatile默认值表达式
2. 对于大型表的批处理策略
3. 在迁移过程中确保数据一致性的机制
4. 回滚方案的设计

最佳实践

基于这个问题，我们建议：

1. 尽量避免在大型表上使用volatile默认值
2. 如果必须使用，考虑使用应用层逻辑而非数据库默认值
3. 对于必须使用数据库默认值的情况，采用分阶段迁移策略
4. 在生产环境执行前，先在测试环境评估迁移时间

这个问题展示了数据库迁移工具在保证零停机时间目标时面临的挑战，以及理解底层数据库行为的重要性。pgroll项目通过识别这类问题并开发针对性的解决方案，为复杂数据库迁移提供了更可靠的执行路径。