Re: Protocol Compression (fourth attempt)

Hi Anthonin,

On 29 Sep 2026, Anthonin Bonnefoy wrote:
> I've also taken a different approach for the implementation, so I
> haven't reused code from the previous attempts.

Could we combine our efforts on this?

Thanks, Michael, for linking my proposal. My goal is a minimal,
future-proof design: a small useful protocol and configuration
interface, with a clear way to negotiate extensions later. My takeaway
from the previous attempts is that expanding scope kept us from
agreeing on that core.

Your PQcommMethods layer looks like a good fit. The separate msg_buffer
avoids copying decompressed messages back into the input buffer, as my
prototype does. I would also like to keep your trace-based tests for
compressed messages and frame boundaries.

There are several choices I would simplify for v1:

- Multiple codecs, levels and long-distance matching. I would start
with Zstandard at its default level.
- Switching codecs within a session and identifying them in every
wrapper. Choosing once at startup avoids those state transitions.
- Compressing additional message types and listing their types in the
wrapper. Starting with DataRow and CopyData leaves other messages
visible to poolers without that extra metadata.
- GUCs for thresholds and batch sizes. We can improve the buffering
policy while keeping these choices internal.
- Configurable frame lifetime. I agree with your suggestion to remove
that option and settle on a mandatory reset rule for poolers.

I am open to using your patchset as the base and reducing its scope, or
taking your implementation ideas into mine. We can choose the base
once we agree on the common design.

Thank you!

Best regards, Andrey Borodin.