Athena/Trino联邦查询比PostgreSQL FDW慢，因前者默认全量拉取远程数据再过滤，后者支持谓词、JOIN、GROUP BY等下推；性能差异由架构决定，非配置问题。
为什么 Athena/Trino 的联邦查询比 PostgreSQL FDW 慢得多
因为底层数据拉取方式完全不同：FDW 是按需下推谓词、字段、LIMIT，而 Athena/Trino 默认把整张远程表（或大分区）全量拉到计算层再过滤。不是配置问题，是架构决定的。
-
Presto/Trino的mysql或postgresqlconnector 默认不自动下推WHERE条件，除非目标库支持且 connector 显式启用（如mysql.case-insensitive-name-matching=true不影响下推） -
Athena的mysql/postgres连接器（通过 Athena Query Federation SDK 构建）默认只下推简单等值条件，IN、范围查询、函数表达式基本不走下推 -
PostgreSQL FDW（如postgres_fdw）在 10+ 版本后支持较完整的下推：包括JOIN、GROUP BY、大部分WHERE子句，只要远程库能执行，本地就尽量不下发原始扫描
怎么让 Trino/Athena 实际用上谓词下推
不能靠“开启某个开关”一劳永逸，得逐连接器确认能力边界，并手动约束 SQL 写法。
- 查
system.metadata.table_comments看 connector 是否标记了supports-predicate-pushdown=true（Trino），但该字段只是声明，不保证生效 - Trino 中对 MySQL 表做
EXPLAIN (TYPE DISTRIBUTED)，看ScanFilterProjectNode下是否有RemoteExchange—— 如果有，说明过滤没下推；如果只有TableScanNode且含filter字段，才算真正下推 - Athena 要检查
QueryExecutionStatistics.DataScannedInBytes：同样一条SELECT * FROM remote_table WHERE id = 123，如果扫了 GB 级数据，基本可断定没下推；正常应只扫 KB 级 - 避免在
WHERE里写UPPER(name) = 'ABC'或date_trunc('day', ts) = current_date—— 这类表达式几乎必然导致全表拉取
FDW 在什么场景下反而更慢甚至失败
不是所有情况 FDW 都赢。当远程表极宽（上百列）、单行极大（JSON/BLOB 占比高），或网络延迟高但带宽足时，FDW 的同步阻塞模型会卡死整个查询计划。
-
postgres_fdw默认使用同步查询协议，一次只能发一个请求，无法并发拉多个分区 —— 对跨月分区的sales_2024_01…sales_2024_12，它会串行连 12 次数据库 - 远程库若无索引，FDW 下推的
WHERE仍要全表扫，但此时数据已从远端流式传回本地，网络 + 序列化开销叠加，比 Trino 在远端内存中扫完再传结果更重 - FDW 不支持远程
LIMIT/OFFSET下推到分页查询（如LIMIT 10 OFFSET 1000），会把全部匹配行拉回来再截断，OOM 风险高
别忽略连接池和超时配置的实际影响
性能差异里，至少 30% 出自连接管理 —— 尤其在高并发小查询场景下。
- Trino 的
mysqlconnector 默认每节点最多 5 个连接，max-connection-lifetime=30m；而postgres_fdw的postgres_fdw.max_connections（9.6+）默认为 0（不限），但实际受限于远程库max_connections和本地shared_buffers - Athena federation 的 Lambda 执行时间上限是 15 分钟，一旦远程查询超时，整个联邦查询直接失败，不会重试或降级；FDW 则抛出
ERROR: connection to server was lost，至少能捕获重试 - 所有方案都怕 DNS 波动 —— Trino/Athena 通常复用连接，DNS 失效后新连接建不起来；FDW 每次查询都可能新建连接，更容易暴露解析失败，但日志里只显示
could not connect to server，看不出是 DNS 还是 auth 问题
复杂点在于：没有通用“最优方案”，只有“当前 schema + 查询模式 + 基础设施 SLA”下的相对合理选择。比如你查的是日志表、每天新增 2TB、只按时间范围过滤 —— FDW 的分区剪枝能力可能碾压 Trino；但如果你要关联 5 个不同云厂商的 MySQL 实例做实时报表，FDW 的运维成本和单点故障风险就远高于 Trino 的 connector 模型。
