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
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 |