Re: PostgreSQL in-transit compression for a client connection

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: PostgreSQL in-transit compression for a client connection
Дата
Msg-id CABUevEzmdNN9DTfAvDXE_bm1xQJhkSFLvB592e24G=wtizDuXg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PostgreSQL in-transit compression for a client connection  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: PostgreSQL in-transit compression for a client connection  (Dominique Devienne <ddevienne@gmail.com>)
Список pgsql-general
On Thu, Apr 27, 2023 at 11:55 AM Laurenz Albe <laurenz.albe@cybertec.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/



В списке pgsql-general по дате отправления:

Предыдущее
От: jian he
Дата:
Сообщение: pg_class char type should be "char"?
Следующее
От: Dominique Devienne
Дата:
Сообщение: Re: PostgreSQL in-transit compression for a client connection