PostgreSQL查询bytea字段时网络传输流量达预期值两倍的问题咨询

你观测到的传输体积翻倍现象，是PostgreSQL客户端-服务端通信协议的默认序列化规则导致的，和存储层压缩、业务侧编码转换无关：

• bytea类型默认采用hex格式传输：PostgreSQL协议默认不会直接透传bytea的原始二进制流，默认bytea_output参数值为hex，会将每1个原始字节转码为2个十六进制ASCII字符传输，算上少量协议帧开销，最终socket层传输体积刚好是原始存储大小的2倍左右，和你观测到的10MB存储对应20MB传输量完全吻合。
• psql、psycopg2默认都沿用这个规则：你觉得psycopg2不会做编码转换的判断并不准确——hex转码是服务端序列化结果阶段就完成的，psycopg2收到hex格式的报文后，会在客户端本地自动解码为原始二进制对象返回给上层业务，因此你在代码里拿到的bytea值长度是正常的10MB，但socket链路上跑的已经是转码后的2倍体积内容，这个过程不属于常规的字符集编码转换，所以你之前排查编码问题没找到异常点。
• text类型高熵内容体积超标是转义规则导致：普通lorem ipsum文本全部是可打印标准ASCII字符，传输时不需要额外处理，体积和存储大小一致；当你使用随机扩展ASCII值（字节值0x80~0xFF）时，对于不属于当前客户端编码可识别范围、或不可打印的字符，PostgreSQL会将其转义为多字节转义序列传输，内容熵越高、需要转义的字符占比越高，最终传输体积就会明显超出原始存储大小。
• 你配置的表级压缩禁用策略只作用于磁盘存储层，完全不影响服务端向客户端返回结果时的序列化转码逻辑，因此不会改变传输层的体积表现。

• 快速验证：在查询前执行SET bytea_output = 'escape';修改当前会话的bytea输出格式，再次抓包观测就能看到传输体积明显下降。注意escape格式仍会对部分不可打印字节做转义处理，无法做到传输体积和原始存储1:1匹配。
• 彻底消除转义开销：
  • 拉取大体积bytea字段时不要使用普通SELECT逻辑，改用PostgreSQL大对象（Large Object）接口传输二进制内容
  • 使用psycopg2时开启二进制传输协议，跳过文本格式的hex转义步骤，可让socket传输体积和实际存储大小基本一致

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