Re: [PATCH] COPY .. COMPRESSED

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PATCH] COPY .. COMPRESSED
Дата
Msg-id CA+TgmoZEWaTAoXm8STcFP6rEa3rNBQFaLL=h8cWzSut+CDyr7w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] COPY .. COMPRESSED  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] COPY .. COMPRESSED  (Bruce Momjian <bruce@momjian.us>)
Re: [PATCH] COPY .. COMPRESSED  (Claudio Freire <klaussfreire@gmail.com>)
Список pgsql-hackers
On Tue, Jan 15, 2013 at 4:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I find the argument that this supports compression-over-the-wire to be
> quite weak, because COPY is only one form of bulk data transfer, and
> one that a lot of applications don't ever use.  If we think we need to
> support transmission compression for ourselves, it ought to be
> integrated at the wire protocol level, not in COPY.
>
> Just to not look like I'm rejecting stuff without proposing
> alternatives, here is an idea about a backwards-compatible design for
> doing that: we could add an option that can be set in the connection
> request packet.  Say, "transmission_compression = gzip".

But presumably this would transparently compress at one end and
decompress at the other end, which is again a somewhat different use
case.  To get compressed output on the client side, you have to
decompress and recompress.  Maybe that's OK, but it's not quite the
same thing.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Event Triggers: adding information
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [PATCH] COPY .. COMPRESSED