Re: PostgreSQL in-transit compression for a client connection

On Thu, Apr 27, 2023 at 11:24 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
wrote:

> On Thu, 2023-04-27 at 14:48 +0530, Tushar Takate wrote:
> > Does PostgreSQL support in-transit compression for a client connection?
>
> No, not any more.
>

On a related but different subject, as someone who must store ZLIB (from
ZIP files)
and sometimes LZ4 compressed `bytea` values, I often find it's a shame that
I have
to decompress them, send them over the wire uncompressed, to have the
PostgreSQL
backend recompress them when TOAST'ed. That's a waste of CPU and IO
bandwidth...

I wish there was a way to tell the backend via libpq and the v3 (or later)
protocol:
Here's the XYZ compressed value, with this uncompressed size and checksum
(depending on the format used / expected), and skip the
decompression/re-compression
and fatter bandwidth, to store them as-is (in the usual 2K TOAST chunks).

I know this is unlikely to happen, for several reasons. Still, I thought
I'd throw it out there.

PS: BTW, in my testing, on-the-wire compression is rarely beneficial IMHO.
I tested the
break-even bandwidth point in the (industry-specific) client-server
protocol I worked on,
which optionally supports compression, and those bandwidths were quite low.
The CPU cost of
ZLib (~ 4x compression) and even the faster LZ4 (~ 2x compression) and
decompression
at the other end, are high enough that you need quite low bandwidth to
recoup them on IO. FWIW.