Re: libpq compression (part 3)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jacob Burroughs <jburroughs(at)instructure(dot)com>
Cc: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: libpq compression (part 3)
Date: 2024-01-12 20:45:43
Message-ID: CA+TgmoY4LWvb2WYRT74UMaKZt+4g2NwCEOQ1KLe94EsphKWNTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 31, 2023 at 2:32 AM Jacob Burroughs
<jburroughs(at)instructure(dot)com> wrote:
> I ended up reworking this to use a version of this option in place of
> the `none` hackery, but naming the parameters `compress` and
> `decompress, so to disable compression but allow decompression you
> would specify `libpq_compression=gzip:compress=off`.

I'm still a bit befuddled by this interface.
libpq_compression=gzip:compress=off looks a lot like it's saying "do
it, except don't". I guess that you're using "compress" and
"decompress" to distinguish the two directions - i.e. server to client
and client to server - but of course in both directions the sender
compresses and the receiver decompresses, so I don't find that very
clear.

I wonder if we could use "upstream" and "downstream" to be clearer? Or
some other terminology?

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-01-12 20:47:13 Re: Recovering from detoast-related catcache invalidations
Previous Message Tom Lane 2024-01-12 20:32:48 cfbot is failing all tests on FreeBSD/Meson builds