PostgreSQL dblink扩展性能过慢及相关技术问题咨询

针对你遇到的dblink跨库查询性能远低于同库的问题，我来逐一拆解你的疑问：

1. dblink性能过慢的原因是什么？ #

dblink的性能瓶颈主要来自这几个核心点：

• 网络传输成本：跨库查询时，远程数据库执行完select id from b_test2后，需要把百万条结果通过网络序列化传输到本地，这中间的网络延迟、数据序列化/反序列化都会叠加出巨大开销；而同库的UNION ALL是在数据库内部直接合并数据，完全没有网络成本。
• 优化器无法参与远程规划：本地PostgreSQL的查询优化器拿不到远程表的统计信息，也不能把过滤、排序等操作下推到远程执行，只能等远程把全量数据传回来再处理。而同库表可以利用并行扫描、缓存共享等优化手段，效率自然高很多。
• 函数调用的额外开销：dblink是以函数调用的方式执行远程查询，Function Scan节点本身的执行机制就不如本地表的Seq Scan高效，没办法利用索引、并行查询等优化特性。

2. PostgreSQL官方或扩展开发者是否计划优化该性能问题？ #

其实PostgreSQL社区已经有了更高效的跨库访问方案——postgres_fdw（Foreign Data Wrapper），它就是为解决dblink的性能短板设计的：fdw允许本地优化器参与远程查询规划，比如把过滤条件下推到远程，只传输需要的数据，还能支持索引扫描、并行查询等优化。

至于dblink，它属于比较早期的跨库扩展，官方现在的重点是完善fdw而非优化dblink，毕竟fdw是更现代、更贴合PostgreSQL架构设计的方案。如果需要跨库查询的高性能，优先推荐切换到postgres_fdw，而非等待dblink的性能优化。

3. TotalCost的含义是什么？应使用哪些指标解读查询性能？ #

TotalCost是PostgreSQL查询优化器估算的执行成本，它是一个抽象单位（大致对应磁盘页面读取的开销），优化器会根据表的统计信息（比如行数、数据分布）估算每个执行节点的成本，进而选择成本最低的执行计划。但这个值是估算的，和实际耗时没有直接线性关系。

解读查询性能应该重点看这些实际指标：

• Actual Total Time：执行节点的实际总耗时，这是最直观的性能指标。
• Actual Rows：实际返回的行数，用来验证优化器的估算是否准确。
• Buffers（若执行计划包含）：显示磁盘IO开销，比如缓存命中情况。
• 执行节点类型：比如是否用到并行扫描（Parallel Seq Scan）、索引扫描（Index Scan），这些直接影响执行效率。

4. 为何b_test1的TotalCost（14425）高于Function Scan的TotalCost（10），但实际耗时却远更低？ #

核心原因是优化器对dblink的成本估算严重不准确：

• 对于同库的b_test1，优化器有完整的表统计信息（行数、数据大小等），能准确估算出扫描全表的成本，所以TotalCost（14425）接近实际执行开销，再加上是本地操作无网络成本，实际耗时自然很低。
• 对于dblink的Function Scan，优化器无法获取远程表的统计信息，只能给出一个非常粗略的默认低成本（比如10），但实际执行时，远程要扫描百万条数据还要通过网络传输，这些真实开销都没被估算进去，所以出现了估算成本低但实际耗时高的反差。

内容的提问来源于stack exchange，提问作者fatih kosal