在PostgreSQL的逻辑复制体系中，行过滤是一个很有用的能力：发布表时可以通过WHERE条件只把满足业务规则的数据变更发送给订阅端。这个机制常被用于数据分发、多租户隔离、敏感数据剥离等场景。然而一旦启用行过滤，不少DBA会发现订阅端延迟开始上升，甚至出现日志积压。这里需要先明确一个核心事实：行过滤的计算发生在发布端，而不是订阅端。
一、行过滤在发布端的执行机制
PostgreSQL的逻辑复制基于发布和订阅模型。发布端通过pgoutput逻辑解码插件读取WAL中的行变更，并根据发布定义中的行过滤规则筛选数据。创建发布时可以针对单个表设置WHERE条件，例如只发布状态为 active 的订单数据：
CREATE PUBLICATION pub_orders FOR TABLE orders WHERE (status = 'active');
这段定义的作用并不是简单地在订阅端忽略不需要的数据，而是在发布端解码WAL时，对orders表产生的INSERT、UPDATE、DELETE逐行执行 status = 'active' 这个条件。只有条件判断为真的行变更才会被写入逻辑复制流并发送给订阅端。换言之，即使订阅端只关心少部分数据，发布端仍然需要读取并解码所有行变更，再通过过滤器丢弃不符合条件的部分。对于INSERT和UPDATE，系统可以从WAL记录中还原出新行数据；对于DELETE或UPDATE旧版本，还原旧行数据可能还需要访问表或索引，这取决于replica identity设置。
因此，行过滤的优势在于减少网络传输和订阅端写入压力，代价是将过滤计算前置到发布端。在数据量较大、过滤条件较复杂、或者主表缺少合适索引时，这种前置计算会成为复制延迟的重要来源。理解这一点对于后续排查和优化非常关键。
二、过滤策略导致延迟升高的原因
过滤策略带来的延迟并不是单一因素造成的，通常可以从解码成本、过滤表达式计算、replica identity配置以及订阅端apply能力几个方面分析。
第一，解码成本不会因为过滤而消失。逻辑解码需要处理所有被发布表的WAL变更，发布端walsender进程必须把每行数据从WAL记录中还原出来，才能执行过滤表达式。如果一张表更新频繁，即使过滤后只剩百分之一的行，解码进程仍然要处理百分之百的变更量。发布端CPU使用率会随WAL生成速度上升，当CPU资源紧张时，逻辑解码开始跟不上WAL产生速度，延迟就会持续增长。
第二，过滤表达式本身可能很昂贵。例如条件中使用函数调用、类型转换、正则表达式、JSON字段访问或者在过滤条件中关联其他表查询，都会显著增加每一行变更的求值开销。即使是简单的字符串比较，如果涉及排序规则或字符集转换，也可能在高并发写入下被放大。一个常见的误区是认为WHERE条件越精确越好，但如果条件无法利用索引或需要额外计算，反而会拖慢发布端解码。
第三，replica identity配置对UPDATE和DELETE影响巨大。如果表没有主键也没有唯一索引，默认的replica identity是NOTHING，此时UPDATE和DELETE不会包含旧行数据，逻辑解码无法还原足够信息，订阅端也无法正确应用变更。很多环境会将replica identity设置为FULL，通过全行数据来识别旧行。但FULL模式要求PostgreSQL在WAL中记录所有列，并且执行UPDATE或DELETE时需要通过索引或顺序扫描找到旧行版本。过滤策略叠加FULL模式时，发布端需要额外读取旧行数据，如果表很大且没有合适索引，延迟会非常明显。
第四，订阅端apply进程的并行能力和事务处理方式也会影响整体延迟。当发布端过滤后仍有大量事务到达订阅端，订阅端如果启用同步提交或者频繁执行约束检查、触发器，都会降低apply速度。此时虽然延迟表现在订阅端，但根源可能仍是过滤策略没有减少足够的数据量，或者发布端解码输出已经变慢。
三、降低过滤复制延迟的优化手段
要降低延迟，首先需要确认瓶颈在发布端还是订阅端，然后针对性地调整。可以使用以下SQL查看逻辑复制的槽位状态和订阅端延迟：
SELECT slot_name, active, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots WHERE slot_type = 'logical';
SELECT subname, received_lsn, latest_end_lsn,
pg_size_pretty(pg_wal_lsn_diff(latest_end_lsn, received_lsn)) AS apply_lag
FROM pg_stat_subscription;
如果发布端的pg_stat_replication显示write_lag、flush_lag、replay_lag持续增大，说明订阅端消费慢；如果这些值较小但槽位confirmed_flush_lsn与当前WAL位置差距很大，说明发布端解码或过滤阶段已经变慢。确认瓶颈后可以采取以下优化措施。
优化过滤条件。尽量让过滤条件使用简单、稳定且能利用索引的表达式，避免在WHERE中调用函数或进行复杂类型转换。例如将 WHERE to_char(created_at,'YYYYMM') = '202501' 改成范围查询，或者对表达式结果物化为生成列并建立索引。当然行过滤本身不直接使用索引，但如果表达式可以利用已有索引，发布端在还原旧行数据时可能受益。更重要的是减少每行求值开销。
合理设置replica identity。如果订阅端需要对UPDATE和DELETE进行精确匹配，优先使用主键或唯一索引作为replica identity，避免使用FULL。只有确实无法提供主键时才使用FULL，并确认相应列上有可用于定位旧行的索引。示例：
ALTER TABLE orders REPLICA IDENTITY USING INDEX orders_order_no_uidx;
如果表没有任何唯一约束，可先创建唯一索引，再将其设置为replica identity。需要注意的是，设置replica identity会改变WAL记录的内容，建议在业务低峰操作，并重新创建受影响的复制槽或重新同步数据。
调整订阅端并行参数。PostgreSQL订阅端支持并行初始数据同步和逻辑apply worker。适当提高max_logical_replication_workers和max_sync_workers_per_subscription可以提升订阅端并发处理能力。但并行apply受事务边界限制，对于小事务高并发场景，单进程瓶颈仍可能存在。示例：
ALTER SYSTEM SET max_logical_replication_workers = 8; ALTER SYSTEM SET max_sync_workers_per_subscription = 4; SELECT pg_reload_conf();
还可以调整订阅端的wal_receiver_status_interval参数，让订阅端更频繁地向发布端报告进度，避免发布端槽位积压过多WAL。该参数默认10秒，在长事务或大事务复制中，适当缩短到2到5秒可以帮助发布端及时推进restart_lsn。
四、监控与持续排查建议
过滤复制延迟往往是动态变化的，需要建立持续监控，而不是出现问题时才排查。发布端可以监控pg_stat_replication中的延迟字段，也可以对逻辑复制槽的confirmed_flush_lsn和当前WAL插入位置做差值计算。订阅端则通过pg_stat_subscription观察收到的LSN与已应用LSN的差距。下面SQL可粗略评估发布端到订阅端的整体延迟：
SELECT slot_name,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS total_lag
FROM pg_replication_slots
WHERE slot_type = 'logical';
如果发现延迟与业务写入量呈明显正相关，可以考虑将过滤逻辑拆分为多个发布或订阅。例如把高频小表与低频大表分开，避免一个慢速订阅拖累所有表的复制；或者将复杂过滤拆成多个简单条件，分别发布到不同订阅端再汇总。此外，定期检查发布定义中的行过滤条件，确认没有遗留已失效的函数或复杂表达式。PG15及以上版本可以通过pg_publication_tables视图查看当前发布的行过滤条件：
SELECT pubname, schemaname, tablename, rowfilter FROM pg_publication_tables WHERE pubname = 'pub_orders';
在排查过程中，如果条件允许，可以临时关闭行过滤，观察延迟是否显著下降。这个对比实验能快速判断过滤表达式是否为延迟主因。如果关闭过滤后延迟没有改善，则需要重点检查订阅端apply进程、网络带宽、磁盘IO以及发布端WAL生成速度。逻辑复制延迟没有单一解决方案，但通过理解过滤策略在发布端的执行机制，结合参数调整和监控数据，通常可以将延迟控制在可接受范围。
PostgreSQL逻辑复制行过滤复制延迟修改时间：2026-08-20 01:19:49