On Thu, Apr 27, 2023 at 11:24 AM Laurenz Albe <laurenz.albe@xxxxxxxxxxx> 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.
