Re: PostgreSQL in-transit compression for a client connection

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Dominique Devienne <ddevienne(at)gmail(dot)com>, Tushar Takate <tushar11(dot)takate(at)gmail(dot)com>, daniel(at)yesql(dot)se, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: PostgreSQL in-transit compression for a client connection
Date: 2023-04-28 07:02:57
Message-ID: CABUevEzmdNN9DTfAvDXE_bm1xQJhkSFLvB592e24G=wtizDuXg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Apr 27, 2023 at 11:55 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>
> On Thu, 2023-04-27 at 11:44 +0200, Dominique Devienne wrote:
> > 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...
>
> That's not what you were looking for, but why not store the compressed data
> in the database (after SET STORAGE EXTERNAL on the column) and uncompress
> them after you have received them on the client side?

That assumes you only have one client. You may want to use the
transparent compression/decompression from some clients and not for
others.

I think it'd be a useful feature to have, but it's not something that
we have today or that I'm aware of being on anybodys radar. So most
likely, for now you're stuck with either what you're doing today, or
as Laurenz suggests handle it completely in the application. You can't
do the mix.

--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dominique Devienne 2023-04-28 11:33:55 Re: PostgreSQL in-transit compression for a client connection
Previous Message jian he 2023-04-28 04:34:53 pg_class char type should be "char"?