Re: Protocol Compression (fourth attempt)

Hi Anthonin,

On 29 Sep 2026, Anthonin Bonnefoy wrote:
> I could start by implementing the simplifications
> you've mentioned to get a v2 on my patch [...]

Would you mind if I prepared that revision of your patchset? It would
help me understand your implementation better and give us a concrete
starting point for combining our work. I'd focus on the simplifications
we agree on.

If you've already started on v2, let me know so we can split the work.

On enabling and disabling compression within a session, I agree that
PQcommMethods makes the switch simple. But a USERSET GUC must handle
SET LOCAL and rollback while output is buffered or a frame is open.
Could we keep the choice at connection startup for v1? Ordinary messages
would still be allowed on a compressed connection, so we could add
session-level control later without changing the wire format. Is there a
use case where choosing at startup would not be enough?

On thresholds and batch sizes, I agree that the knobs are useful for
experiments. Your first-packet timings show that the flush policy needs
work. I'd first try to address that internally, for example by bounding
the amount of uncompressed input processed before flushing output.
Publishing these thresholds as GUCs would mean supporting their
semantics as we change the buffering policy. Could we keep them in a
benchmarking patch for now, and add public controls if measurements
show a trade-off that users need to choose themselves?

Thank you!

Best regards, Andrey Borodin.